Autonomous SI trading agents with governed execution, transparent risk controls and on-chain infrastructure built around Base.
Autonomous intelligence for the markets.
OAA is built around autonomous trading agents that observe markets, reason over signals and context, propose or execute trades within defined permissions, and monitor risk continuously. The goal is controlled automation, not unrestricted automation: intelligence, risk authorization and execution are kept separate.
Development status. The project is under active development. Capabilities are labelled Live, Beta, In Development or Planned. Exchange support, strategy availability, tokenomics, contract addresses and launch parameters are only presented as live once they are finalized and verifiable.
If the Risk Engine blocks a proposed action, the result is no trade. After an exit or adjustment the loop starts again with fresh market data. The agent can identify an opportunity, but permissions and risk controls decide whether it acts: a useful signal does not automatically become an order.
Explore the core product
Trading Agents
The core product layer: autonomous agents for market analysis, governed decisions and trading workflows.
How Agents Trade
The full loop from observation and analysis through risk validation, execution and monitoring.
Risk Engine
How exposure, permissions and execution constraints sit between SI reasoning and the exchange.
Inside the Agent
What an agent can observe, decide, request and execute, and where its authority ends.
Why the architecture matters
Intelligence
Agents combine market observations, strategy logic, context and tool access to form a trade thesis. What appears worth doing?
Control
The risk and execution layers decide whether a proposed action is permitted, within limits and eligible for execution. What is actually allowed to happen?
Four operating principles
Principle
Meaning
Agent-native
Autonomous agents are the primary product layer, not a cosmetic add-on.
Risk-gated
Trade intent is checked against explicit controls before execution.
Transparent
Product status, permissions and on-chain claims can be independently understood and verified.
Human-governed
Users keep control over permissions, limits and consequential actions.
Beyond trading
OAA is designed as a broader SI-agent ecosystem. Trading is the flagship use case; the architecture can also support research, analysis, workflow automation, integrations and future on-chain interactions.
Announcements and community chat. Verify in the public channel to join the group.
Live
Official verification matters. Only links published here or on other verified OAA channels are official. Do not rely on an unverified token contract, treasury address, performance, liquidity or audit claim.
Getting started
Overview
Product thesis, design principles and scope of the OAA ecosystem.
OAA is being designed as an SI-agent ecosystem that combines intelligent autonomous software with blockchain infrastructure on Base. Product capabilities, technical architecture, token mechanics and security controls are documented separately and verified as they mature.
What OAA is designed to enable
Specialized SI agents for research, analysis, automation and digital workflows.
Tool-enabled execution through explicitly authorized APIs, integrations and services.
Permission-aware operations, with reasoning and execution kept as separate security boundaries.
On-chain infrastructure for transparent ownership, settlement and ecosystem mechanisms.
Verifiable documentation for contracts, treasury controls, vesting, liquidity and audits once deployed.
Product model
User objective→SI agent→Context, memory & approved tools→Permission boundary→Verified result / Base execution
An agent may judge an action useful, but consequential execution still requires authorization and is subject to system policy.
Documentation model
Status
Meaning
Live
Available in production and documented as currently usable.
Beta
Available in a limited or evolving production form.
In Development
Being built or tested; not presented as generally available.
Planned
Part of the intended architecture or roadmap, with no production commitment yet.
Tokenomics, contract addresses, vesting schedules, liquidity details and other launch parameters are only presented as final once they are verifiable.
Core principles
SI-native: agents are the core product layer, not an add-on.
On-chain capable: blockchain interactions are built around Base infrastructure.
Transparent: material token, treasury, vesting and liquidity information should be independently verifiable once deployed.
Security-conscious: agent permissions, smart-contract controls and wallet interactions are documented explicitly.
Utility-focused: token functionality is tied to defined ecosystem functions rather than unsupported promises.
Getting started
Vision & Mission
The long-term direction and operating mission behind OAA.
Vision
OAA aims to build an ecosystem in which SI agents help users complete complex digital workflows, while blockchain infrastructure provides transparent ownership, settlement and verifiable economic coordination. The direction is not simply to add intelligence to a crypto product or a token to an SI interface. The architecture keeps four areas separate so each can be improved and audited independently:
Intelligence
Execution
Authorization
Economic infrastructure
Mission
Make sophisticated SI-agent capabilities accessible through one coherent platform, with explicit controls over permissions, data access, tool usage and on-chain execution.
Three-part operating model
Layer
Responsibility
Intelligence
Interprets intent, reasons over context and coordinates specialized agents.
Application
Exposes workflows, integrations and user controls through a consistent product layer.
Blockchain
Supports verifiable ownership, settlement and future ecosystem mechanisms on Base.
Design philosophy
The documentation separates what is live, in development and planned, so the project is understandable without presenting future concepts as current facts.
A feature becomes part of the documented production system only once its implementation, permissions and operational limitations can be described accurately.
Trading
Trading Agents
OAA’s core product: autonomous agents that analyze markets, operate within defined permissions and carry out governed trading workflows.
Agents are designed to monitor markets, interpret data, evaluate opportunities and execute approved workflows, always within explicit risk and permission limits.
Product status. This section describes the intended architecture, not confirmed production capabilities. Exchanges, strategies, assets, venues and capabilities will carry a status label (Live, Beta, In Development, Planned) once verified.
What makes an agent autonomous?
An autonomous agent is more than a signal generator. It follows a controlled decision loop: observe, analyze, decide, validate, execute and monitor.
A rejected thesis ends in no trade; after an exit, adjustment or hold the loop returns to market data.
Core responsibilities
Observe
Continuously evaluate permitted market data and relevant context.
Reason
Form a trade thesis from the configured strategy and available evidence.
Validate
Run proposed actions through portfolio, permission and risk checks before execution.
Execute
Place only actions that the configured execution policy allows.
Monitor
Track positions and respond to changing conditions, limits or exit criteria.
Explain
Record decision context so users can see what the agent did and why.
Agent profiles
OAA may support specialized agents rather than one general model. Potential profiles include:
Market scanning
Trend following
Mean reversion
Portfolio coordination
Execution
Risk oversight
Specific profiles are listed as product capabilities only after their behaviour, permissions, supported markets and status are confirmed.
Human control
Autonomy stays bounded. Users keep control over:
Which accounts an agent can access
Which actions it can take
How much capital it may use
When trading must stop
Trading
How Agents Trade
A transparent view of the trading loop, from market observation through execution to post-trade monitoring.
OAA uses a staged trading loop instead of a single opaque model output, so the path from information to action stays understandable.
The trading loop
Observe: the agent receives only the market data, account context and external signals its configuration permits.
Build a trade thesis: evidence is evaluated against the strategy rules and a candidate action is formed: no trade, enter, reduce, exit or adjust.
Validate risk: before execution, the action is checked against hard constraints such as position limits, exposure limits, account permissions and other configured controls.
Execute: only an approved action reaches the execution layer, which should use the minimum account permissions needed for trading.
Monitor: after execution the agent keeps tracking market conditions, position state and relevant risk thresholds.
Exit or adapt: the agent decides whether to hold, reduce, close or otherwise adjust the position according to its permitted policy.
A decision is more than a signal
Market data sends the current market state to the trading agent.
User controls provide the strategy and permissions.
The agent sends a proposed action to the Risk Engine.
The Risk Engine approves or rejects it.
Only approved orders go to the exchange / execution layer.
Execution returns a result to the agent.
The agent reports decision, status and outcome to the user.
No trade is a valid decision
An autonomous agent is never forced to trade. No trade is a valid, and often necessary, outcome when conditions are weak, data is insufficient, risk limits are reached or permissions do not allow an action.
Autonomous trading does not remove market risk. SI models can be wrong, markets can change quickly and execution can differ from expected results.
Trading
Risk Engine
The control layer that constrains autonomous trading before an order reaches an exchange.
The Risk Engine is an independent control boundary between an agent’s trading decision and execution. Core principle: an agent may identify an opportunity without automatically being allowed to act on it.
Decision flow
Permission check→Exposure check→Position / order limits→Market / strategy rules→Approved for execution
Failing any check rejects the trade; only an action that passes all checks is approved.
Control categories
Control
Purpose
Account permissions
Restricts what an agent may do on a connected account.
Position limits
Caps the size of a single position or order.
Portfolio exposure
Constrains aggregate risk across positions or assets.
Asset / venue allowlists
Restricts trading to approved markets or exchanges.
Strategy constraints
Prevents actions outside the configured trading policy.
Emergency controls
Pauses or disables trading when predefined conditions are met.
Hard limits vs. agent judgment
Critical rules are enforced as deterministic constraints outside the reasoning layer, not left to model judgment alone.
Agent judgment
Reading market context, weighing evidence and proposing an action.
A mature deployment should offer a clear way to halt new trading activity, for example a user pause, account disconnect, policy lock or automated circuit breaker. The exact implementation will be published once finalized.
The Risk Engine reduces operational risk but cannot eliminate trading losses, model errors, exchange failures, slippage or extreme market events.
Trading
Inside the Agent
A transparency layer: what a OAA agent can see, decide, request and execute.
Instead of treating the agent as a black box, this section defines the boundaries between information, reasoning, permission, risk and execution.
The five boundaries
Boundary
Description
What it can see
Only data sources, account context and tools explicitly exposed to the agent.
What it can decide
It may form a thesis and propose actions within its configured strategy.
What it can request
Actions can be passed to permission and risk controls for approval.
What it can execute
Only approved operations supported by the connected execution layer.
What it cannot do
Anything outside its permissions, blocked by risk controls or unsupported by the system.
Both the permission boundary and the risk boundary can block an action, which then ends as rejected.
What users should be able to inspect
Where technically available, key context around an action can be shown without revealing private chain-of-thought reasoning:
The strategy or agent profile involved
The market and asset evaluated
The action requested
Relevant risk checks and whether they passed
The execution status
Order or transaction identifiers where applicable
Position state and subsequent actions
Why this matters
Autonomous systems are easier to trust when their boundaries and outputs can be inspected, even if the model’s reasoning is not shown word for word.
The goal is accountable autonomy: agents that act independently within defined rules while users keep visibility and control over consequential actions.
Future transparency features
Agent activity timelines
Risk-event histories
Execution receipts
Strategy versioning
Per-agent status dashboards
These are documented as live only once implemented and verified.
Platform
SI Agent Ecosystem
How OAA agents reason, use tools, verify results and stay under human control.
An agent is software that interprets a user’s objective, reasons over available context, selects permitted tools and executes defined actions within explicit boundaries.
Agent lifecycle
Intent: identify the user’s objective and relevant constraints.
Context: retrieve relevant information, approved memory and task state.
Reasoning: plan a sequence of actions and identify uncertainty or missing requirements.
Tool selection: consider only tools and integrations permitted for the task.
Authorization & execution: consequential actions pass the applicable permission boundary before running.
Verification: check the result before completion is reported.
Capability categories
Category
Description
Status
Research
Gather, compare and synthesize information from approved sources.
In development
Analysis
Work with structured data, documents and task-specific context.
In development
Automation
Coordinate repeatable digital workflows across connected tools.
In development
On-chain interaction
Prepare or execute blockchain actions subject to explicit authorization.
Planned / staged
Human control
Reasoning is not authorization. An agent judging an action useful does not by itself grant permission to move assets, sign transactions, expose credentials or perform other consequential operations.
Sensitive workflows use explicit confirmations, scoped credentials, least-privilege tool access and auditable execution boundaries.
Platform
Architecture
A layered technical architecture: intelligence, orchestration, tools and Base infrastructure.
OAA is a layered system, so intelligence, application logic, authorization and blockchain execution can each change independently.
User / Application→Agent orchestration→Intelligence & tools→Policy & permissions→Execution→Base & external services→Verification & result
1. Intelligence layer
Coordinates language models, task reasoning, contextual retrieval and agent-specific instructions. Model output is a decision input, not an authorization primitive.
2. Agent orchestration
Maintains objectives, task state and tool selection, and handles retries, intermediate results and workflow progression.
3. Tools & integrations
Agents can be extended through explicitly authorized APIs, applications and data sources. Each integration defines the data it can access and the actions it can perform.
4. Policy & permissions
Decides whether a proposed action is allowed, requires confirmation or must be blocked. This boundary matters most for wallets, credentials and external side effects.
5. Blockchain layer
Planned around Base. Possible on-chain components include token functionality, smart-contract interactions, treasury operations and other ecosystem mechanisms, once finalized.
Security boundary
Decision
Responsible layer
What action could solve the task?
Agent reasoning
Which tool could perform it?
Orchestration
Is the action permitted?
Policy / authorization
Was it executed successfully?
Execution + verification
This separation reduces the risk of treating model output as an unrestricted command channel.
Platform
Built on Base
The planned Base blockchain foundation and how official deployments will be verified.
OAA is planned to use Base for future on-chain components. Blockchain infrastructure offers transparent settlement, token ownership and auditable smart-contract state. Plans and actually deployed, verified contracts are always kept apart.
Deployment information
Item
Publication standard
Network / chain
Exact network identification and deployment environment
Token contract
Official address and verified explorer reference
Smart contracts
Contract purpose, version and administrative permissions
Treasury
Official addresses and documented control model
Vesting
Contract addresses, allocation rules and unlock mechanics
Liquidity
Pool or position information and any lock mechanism
Verification model
Official publication: a deployment detail is released through verified OAA documentation or another official channel.
On-chain verification: users can independently inspect the contract or transaction on Base.
Documentation match: address, version and described permissions must match the deployed implementation.
No token contract, treasury address or liquidity claim is official just because it uses the OAA name. Always check against the official documentation first.
Platform
Security & Transparency
Security boundaries, contract transparency and verification standards.
Security documentation is treated as part of the product specification, not as a marketing claim.
Security model
Area
Principle
Agent permissions
Agents receive only the tools and access needed for the current task.
Consequential actions
Wallet, credential and external side-effect operations need explicit authorization boundaries.
Secrets
Sensitive credentials are not exposed to unnecessary components or stored without a defined need.
Verification
Execution results are checked before a workflow is reported as complete.
On-chain controls
Administrative permissions and control mechanisms are documented for deployed contracts.
Token and contract transparency
After deployment the documentation identifies the official token contract, relevant administrative permissions, treasury addresses and the contracts responsible for vesting or liquidity management.
Team token vesting
Team allocations follow a defined vesting structure. Final allocation, cliff, unlock frequency and duration are published once tokenomics are finalized.
Liquidity
If liquidity is described as locked, the lock provider or mechanism, the position or transaction identifiers and the lock duration are published so the claim can be verified.
Audits
An audit is labelled completed only when a genuine third-party report exists, stating its scope, date and the contract version reviewed.
An audit reduces specific classes of risk but does not guarantee that a contract, protocol or economic mechanism is risk-free.
SI-agent security
Permission boundaries
Tool restrictions
Transaction authorization
Protection of sensitive credentials
Resistance to prompt injection
Explicit confirmation for consequential operations
Token
Token & Utility
Token allocation, liquidity structure and the planned vesting framework.
Current framework. Total supply is 1,000,000,000 tokens and the allocations add up to 100%. Vesting, wallet and lock details are shown at the level currently defined; exact dates, addresses and parameters are added once finalized.
Token allocation
1BTotal supply
Lock link coming soon
Lock link coming soon
Lock link coming soon
Lock link coming soon
Lock link coming soon
Lock link coming soon
Every lock and wallet is public on Base. Tap Lock or Wallet to check it yourself.
Allocation
Share
Tokens
Liquidity Pool
70%
700,000,000
Reserved Liquidity / Treasury
10%
100,000,000
Team
3%
30,000,000
Marketing / Growth
7%
70,000,000
Ecosystem / Development
7%
70,000,000
Community / Airdrops
3%
30,000,000
Total
100%
1,000,000,000
70% of the total supply goes to the primary liquidity pool. A further 10% is held as a reserve for future liquidity and the treasury. Team, marketing, development and community allocations are kept as separate, identifiable wallets.
Liquidity structure
Item
Share
Tokens
Planned treatment
Liquidity Pool
70%
700,000,000
DEX liquidity, intended to be secured by a publicly verifiable liquidity lock once the pool is created.
Reserved Liquidity / Treasury
10%
100,000,000
Reserved for future liquidity needs and treasury use; every deployment is documented beforehand (wallet source, amount, purpose, transaction references).
Final pool composition, initial price, pool address, LP position and lock evidence are final only once deployed and publicly verifiable.
Liquidity supports market depth but does not guarantee price stability, trading depth or protection from volatility.
Locking, vesting & custody
Allocation
Planned control framework
Liquidity Pool (70%)
LP position locked for 4 years via UNCX and extended before the lock ends, so the liquidity stays locked; lock link and end date published once created.
Reserved Liquidity / Treasury (10%)
Kept separate from operational wallets in multisig custody with publicly documented control policies; used only for documented liquidity or treasury purposes.
Team (3%)
30,000,000 tokens locked via PinkLock: nothing is released before 25 Nov 2027 (00:00 CET); then 4% at the first unlock and 4% every 30 days, fully released after about 24 months.
Marketing / Growth (7%)
70,000,000 tokens: 30,000,000 locked via PinkLock with the first unlock on 25 Jan 2027 (00:00 CET): 4% at the first unlock, then 8% every 30 days, fully released after about 12 months; 40,000,000 unlocked from launch for marketing, partnerships, listings and campaigns. Every marketing spend is sent from a published wallet so it can be followed on BaseScan.
Ecosystem / Development (7%)
70,000,000 tokens locked via PinkLock: nothing is released before 25 Nov 2027 (00:00 CET); then 4% at the first unlock and 8% every 30 days, fully released after about 12 months.
Community / Airdrops (3%)
30,000,000 tokens locked via PinkLock with the first unlock on 25 Jan 2027 (00:00 CET): 4% at the first unlock, then 4% every 30 days, fully released after about 24 months; each release is distributed under published campaign rules, and undistributed balances stay traceable on-chain.
Wallet & lock verification
Wallet addresses, pool address, multisig addresses, lock records and BaseScan links are added once they exist. Entries marked TBD are not created yet.
Potential utility areas: ecosystem access, agent-related services, governance or other platform mechanisms with a defined technical role. Each utility claim must map to an implemented product function or smart-contract mechanism.
Security audit
A CertiK smart-contract audit and security review is planned after the token contract is created and finalized. Planned
Transparency standard
Before launch the documentation should publish:
Official token contract
Allocation wallets
Liquidity-pool details
Reserved liquidity / treasury address
UNCX liquidity lock link
PinkLock vesting links
Multisig addresses
BaseScan verification links
Vesting contracts or schedules
Official security-audit report, where applicable
Nothing here is a promise of price appreciation, yield or investment return. Utility describes intended ecosystem function, not market performance.
Token
Audit & Certification
Security verification for the token and related smart contracts: automated scans and a planned independent audit.
Automated security scans
Planned once the final token contract is deployed and verified. Public report links are added when available.
Verification
Purpose
Status
GoPlus DeepScan
Automated token and contract risk checks, incl. permissions and common token risks.
Planned · after deployment
TokenSniffer
Public token risk and contract checks.
Planned · after deployment
Audit Forge
Automated Solidity security analysis and pre-audit checks.
Planned · before / after deployment
Web3defender
Additional token and wallet security checks.
Planned · after wallets & token are live
These are automated scans, not independent manual audits or certifications. Every completed scan will be linked publicly.
Independent audit
Independent review
Status
Report
CertiK or comparable independent auditor
Planned · after contract creation
TBD
Expected scope: the final token contract and any other security-critical contracts at launch. Once completed, auditor, report, scope, completion date and verification link are listed here.
A contract is only called audited or certified when an official, independently verifiable report exists. Automated scan results stay labelled as automated checks.
Verification standard
Deployed contract on BaseScan
Automated scan results
Relevant wallet verification records
Any future independent audit report
Project
Roadmap
Product, infrastructure and ecosystem milestones, not price targets. Dates are shown only where there is a real development commitment.
Phase 1 · Foundation
In development
Brand and documentation system
Core product architecture
Agent model and permission principles
Base infrastructure planning
Security and transparency framework
Phase 2 · Product development
In development / planned
Agent workflows and orchestration
User-facing application interfaces
Tool and data integrations
Permission and confirmation systems
Testing, observability and verification workflows
Phase 3 · On-chain deployment
Planned
Finalize token and contract architecture
Deploy and verify smart contracts
Implement vesting and treasury controls
Establish liquidity infrastructure where applicable
Publish authoritative contract and treasury references
Phase 4 · Ecosystem expansion
Planned
Additional specialized agents
Broader integrations and developer capabilities
Community and ecosystem features
Governance mechanisms, if implemented and technically justified
Roadmap items show intended sequencing, not guaranteed delivery dates. The documentation is updated as milestones move from planned to implemented.
Project
Risks & Disclaimer
Technical, economic and operational risks of SI agents and blockchain systems.
OAA combines super intelligence, external software integrations and blockchain systems; each adds material technical, operational and economic risk.
Key risk categories
Risk
Description
SI reliability
Models can produce incorrect, incomplete or misleading outputs.
Tool execution
External APIs or integrations can fail, change behaviour or return unexpected results.
Smart contracts
Deployed code can contain defects, vulnerabilities or unintended economic behaviour.
Wallet security
Lost keys, compromised credentials or malicious signing requests can cause irreversible loss.
Blockchain infrastructure
Congestion, outages, bridge failures or network-level events can disrupt operations.
Liquidity & volatility
Digital-asset markets can see extreme price swings and limited liquidity.
Regulatory change
Laws, classifications and compliance obligations can change across jurisdictions.
User responsibility
Users should assess the relevant risks independently, verify official contract information and understand the consequences of transactions before interacting with any blockchain component.
Never send funds or sign transactions based only on an unverified address, social-media post, direct message or third-party listing. Confirm official deployment information against this documentation.
Disclaimer
Nothing in this documentation is financial, investment, legal or tax advice.
Digital assets are highly volatile and may lose part or all of their value.
References to planned features, token utility or roadmap items are forward-looking and not guarantees of delivery or economic outcome.
The OAA Journal · Research & News
Inside the world of Super Intelligence.
Selected reads on superintelligence from leading research labs, plus autonomous agents on Base.
Only links published on oaap.si are official. Telegram: verify you are human in the public channel, then you are sent into the community group automatically.
Questions about the agents? .
OAA · Build log
Every update. Numbered.
What we build, when we build it and how it works. Agent, code and website notes from the OAA team, newest first.
020Updates
27 Oct 2026Latest
Launch Nov 17Status
020
Update 020RiskLatest
SENTINEL checks tokens on every chain
The Rug Check now works for tokens on Base, Ethereum, BNB Chain, Arbitrum, Polygon, Optimism, Avalanche, Solana, Tron and 15 more chains. Paste a contract address, a DexScreener link or a ticker.
Honeypot sell simulation, buy and sell tax, hidden owner, mint, blacklist, proxy and self-destruct checks
Solana: mint, freeze and balance authority, transfer fees and hooks, burned liquidity
Liquidity lock, top holders, pool age and 24h buys/sells for every chain
Base keeps its deep on-chain check (bytecode, proxy slots, holders) plus the new honeypot simulation
sentinel/chains.jsShow code
// paste anything: address, DexScreener link or $TICKERconst t = parseToken(input); // EVM, Solana or Tronconst chain = pickMarket(pairs).chain; // Base first, else most liquidityconst risk = await goplus(chain, t.address);
019
Update 019Agents
23 OAA agents on the x402 marketplace
The OAA agents now sell 23 services over x402, from a $0.05 price check to a $5 deep due diligence report. Agentverse and Portal get their own navigation, so every part opens in its own view.
CORE: ask anything, token explained, market brief, wallet Guardian report, deep due diligence
ZEN: single signal, multi-timeframe, compare up to 5 coins, top 8 and top 20 boards
Paid in USDC on Base straight to the treasury; wrong input is rejected before you are charged
x402/services.jsShow code
// every OAA agent, pay per call in USDC on Basediligence: { agent: 'CORE', price: 5, run: tokenInfo + rugCheck + signals(1h, 4h, 1d) + report },price: { agent: 'AQL', price: 0.05, run: lastPrice(asset) },// bad input never settles the payment
018
Update 018Agents
OAA Guardian and buying with any coin
The Portal gets the OAA Guardian: SENTINEL grades every token in a wallet, ZEN adds signals, CORE writes a daily brief and PROOF anchors its hash on Base. And $OAA can now be bought with BTC, SOL, ETH, USDC or BNB.
Guardian: wallet health score, risk grade A to F per token, 4h signal per position, brief in plain words
Read-only: nothing is signed; 1 free scan per day, more for signed-in $OAA holders
Buy window: pay with BTC, SOL, ETH, USDC or BNB and receive $OAA on Base, signed in your own wallet
BTC and SOL via a one-time deposit address with automatic refunds; 0.3% platform fee to the treasury
guardian/health.jsShow code
// Wallet health: value-weighted risk score of all positionsconst health = positions.reduce((s, p) => s + p.valueUsd * p.score, 0) / positions.reduce((s, p) => s + p.valueUsd, 0);// the brief hash joins the next hourly proof batch on BasequeueBrief({ id, hash: keccak256(brief), createdAt });
017
Update 017Website
Portal: the OAA economy, live on Base
The Portal becomes the home for $OAA holders. It switches on automatically with the launch on 17 November.
Live $OAA price, market cap, liquidity, volume and safety grade
Holder dashboard: balance, value and share of supply, read from Base
Holder perk: 5x the daily Agentverse limit for wallets holding $OAA
Where the launchpad fees go: 0.4% creator, 0.6% OAA Treasury
portal/status.jsShow code
// The Portal opens itself at launch, no redeploy neededconst live = Date.now() >= Date.parse('2026-11-17T16:00:00+01:00');portal.classList.toggle('is-live', live);
016
Update 016Agents
Six agents, one core
The Agentverse is rebuilt around the OAA Core, an orchestrator that sends every request to the right specialist agents and combines their answers.
OAA Core is sold on the x402 marketplace for $0.03 per call, paid in USDC to the treasury
New video: how an agent fetches data, commits it on Base and returns a verified signal
agents/core.jsShow code
// The Core picks the specialists for each requestconst used = [];if (wantsSignal) used.push('ZEN');if (wantsRisk) used.push('SENTINEL');if (wantsScout) used.push('SCOUT');if (wantsProof) used.push('PROOF');
015
Update 015Website
Now OAA Protocol
The project is now OAA Protocol, ticker $OAA. OAA stands for Orchestrated Autonomous Agents. New brain logo, new name across the website, the docs, Sia and the smart contracts.
Wordmark OAA with Protocol, turquoise brain logo
Launchpad contracts renamed to OAALaunchpad and OAAToken
Every token launched on OAA reports poweredBy = OAA Protocol on-chain
The hall shows the countdown to the $OAA launch on 17 November. The site is hardened against attacks and access requests no longer ask for personal data.
Launch countdown under the header
Strict Content Security Policy: only our own scripts can run
No embedding on other sites, HTTPS only, safe headers on every response
Access requests: connect a wallet, no name, no email
Launching a token on OAA now fits in one window: idea, details, images, launch. No $OAA is needed to launch, but every launch supports $OAA.
Super Intelligence Studio: one sentence becomes name, ticker, description, logo and banner
Chain picker: Base live, BNB Chain, Robinhood Chain and Solana coming soon
Opens as a public beta right after the $OAA launch
launchpad/wizard.jsShow code
const steps = ['Idea', 'Details', 'Images', 'Launch'];// step 2 needs a name and a ticker, step 3 a logo and a bannernext.disabled = !valid(steps[current]);
011
Update 011Website
New header, Sia chat and mobile menu
A text-only header over the hall that works everywhere, Sia as a small chat window bottom right, and a compact side menu on phones.
Header with all sections on every page
Ask Sia: chat window instead of a separate page
Sharper hall image (upscaled, responsive sizes)
ui/header.jsShow code
// the same header stays on top, the hall stays visibledocument.body.appendChild(header);header.classList.add('qs-top');
010
Update 010Risk
Rug Check: grade A to F for any token
SENTINEL checks any Base token for owner powers, hidden taxes, upgradeable code, holder concentration and liquidity, and explains every point.
Every hour the ZEN signals are hashed and the hash is written to Base before the outcome is known. They are scored automatically later, and anyone can verify them.
Public track record with hit rate per asset and timeframe
Verify button: recomputes the hash and compares it with the transaction on Base
Nobody, not even OAA, can change a signal afterwards
proof/anchor.jsShow code
// one 0 ETH transaction per hour carries the batch hashconst root = keccak256(concat(signals.map(leafOf)));await keeper.sendTransaction({ to: keeper.address, data: MAGIC + root });
008
Update 008Launchpad
OAA Launchpad on Aerodrome
Anyone can launch a token on Base with locked liquidity from the first second. Part of every trade goes to the OAA Treasury.
Fixed supply of 1B, no minting, no tax, 100% of the liquidity locked forever
1% per trade: 0.4% to the creator, 0.6% to the OAA Treasury
Optional creator first buy in the launch transaction, max $500 in ETH
OAA x Aerodrome
launchpad/fees.solShow code
// split of the collected trading feesuint256 toCreator = amount * 40 / 100;uint256 toTreasury = amount - toCreator;
007
Update 007Agents
Agentverse: live agents and the x402 marketplace
The first live agents: trading data and real swaps you sign yourself, computed signals, and a marketplace of paid agents and APIs over x402.
Swaps through the KyberSwap aggregator, signed in your own wallet
Free during the beta with a fair use limit
x402 marketplace: discover and pay agents in USDC on Base
agents/swap.jsShow code
// the swap is built here, but only your wallet can sign itconst tx = await buildSwap({ token, side: 'buy', amountEth });await wallet.sendTransaction(tx);
006
Update 006Website
One window for everything
The new OAA home: a full-screen hall with the OAA logo. Clicking the logo opens one large glass window where every section lives, so visitors never leave the page.
Agentverse, Documentation, Blog, Updates and Contact as tabs inside the window
The full documentation readable in the window, without leaving the site
Blog with the book-shelf animation and reads on superintelligence
window/tabs.jsShow code
// Every header link swaps the window content in placefunction show(tab) { panels.forEach(p => p.classList.toggle('is-active', p.dataset.panel === tab));}
005
Update 005Code
Concierge: answers with a status label
The new OAA Concierge answers questions from our documentation and shows whether each answer is a draft, planned or still pending.
14 topics grouped into Project, Token, Safety and Launch
Every answer shows its source and a DRAFT / PLANNED / PENDING label
Free-text questions are matched to the closest documented topic
concierge/answer.jsShow code
// Each answer carries its source and how certain it isconst answer = { topic: 'Locks & vesting', text: 'Planned locks: liquidity via UNCX, vesting via Team.Finance ...', source: 'Token & Utility / Locking & Vesting', status: 'PENDING', // DRAFT | PLANNED | PENDING};
004
Update 004Agents
Agentverse and access requests
Visitors can explore every agent and request access with a form that checks the wallet address before it is sent.
Agent overview with CORE, AQL, ZEN, SENTINEL, SCOUT, PROOF and Custom
Access request: connected wallet, agent and optional purpose
No name or email needed, the wallet is the access
agentverse/access.jsShow code
// A Base address is 0x followed by 40 hex charactersconst isBaseAddress = (value) => /^0x[a-fA-F0-9]{40}$/.test(value.trim());
003
Update 003Risk
Risk engine: first permission check
The first design of the check that sits between an agent proposal and execution. An agent can propose, but only this layer can approve.
Asset allow-list per account
Position size and total exposure limits
Every rejection returns a readable reason for the log
risk/approve.jsShow code
function approve(proposal, limits) { if (!limits.assets.includes(proposal.asset)) return reject('asset not allowed'); if (proposal.size > limits.maxPosition) return reject('position too large'); return { status: 'approved', checkedAt: Date.now() };}
Design draft. Logic and limits may change before launch.
002
Update 002Agents
Agent lineup: CORE, AQL, ZEN, SENTINEL, SCOUT, PROOF and Custom
We defined the first four agents and what each one is responsible for. Every agent works inside the same permission and risk framework.
AQL for crypto markets and onchain trade preparation
SENTINEL for risk checks, SCOUT for discovery and PROOF for the verifiable track record
ZEN for explainable signals, plus Custom agents for your own strategy
Super intelligent trading agents and custom agents, powered by the OAA token on Base.
01
Perceive
Agents watch markets, context and onchain data around the clock.
02
Reason
They form a trade thesis and test it against your risk limits.
03
Act with approval
Nothing executes without passing your rules. Every step stays traceable.
Agents
SiaOAA assistant · Free beta
Sia is a super intelligence assistant in beta and can make mistakes. Nothing here is financial advice.
OAA · Launchpad
Launch a token on Base.
1,000,000,000 supply, 100% of the liquidity locked forever on Aerodrome in three ranges up to a $1B market cap. Optional first buy up to $500 in ETH. You earn 0.4% of every trade, 0.6% goes to the OAA Treasury.
All tokens launched on OAA in one place: price, volume, market cap and a live Sentinel risk grade, sorted by category. Buy directly on Aerodrome with your wallet.
