Tako: Humans, agents, and markets on Arc

Whitepaper · Version 0.4 · 16 September 2026

01 / Abstract

Tako is building the agentic finance layer on Arc: a financial network where humans and autonomous agents research markets, trade, and allocate capital together. Arc is Tako's launch chain and canonical home for its proposed registries, initial accounts, and protocol settlement. Its technical foundation is a proposed secure execution network: developers publish identifiable agent software, nodes run approved versions in confidential compute, and humans grant bounded authority that destination-chain contracts independently enforce.

The aim is not simply to make an agent capable of placing an order. It is to connect creation, evaluation, capital, execution, and accountability without turning an open-ended model into an unrestricted account owner. Humans should be able to understand what they approved, observe what happened, revoke authority, and recover control.

The planned applications include agents for trading, lending, borrowing, treasury management, and yield strategies across multiple chains. Lending agents could compare supply markets, borrowing agents could monitor collateral and debt within defined limits, and yield agents could evaluate and manage approved allocations. Arc remains the canonical home and initial execution destination; each additional protocol and chain requires validated adapters, capability-specific controls, and local enforcement before capital can be authorized. These are planned capabilities, not available integrations or promised returns.

Tako is launching in stages: the public website and whitepaper first, followed by a useful research agent inside Terminal, persistent monitoring, paid USDC research delivery, agent creation and evaluation, and bounded financial execution. The first product is intended to investigate a supported Arc token's early buyers and explain subsequent changes with transaction evidence. The broader network remains the ambition; Section 10 separates the build sequence from current availability.

02 / Why Tako

Financial agents combine probabilistic reasoning with consequential actions. Models can misunderstand instructions, tools can fail, external content can be malicious, and a sound strategy can still lose money. A prompt such as “trade carefully” cannot substitute for explicit financial authority.

Developers also face fragmented workflows: research in one environment, testing in another, keys in application configuration, and execution logs that are difficult to compare with an economic outcome. Users need more than an agent directory. They need a way to assess an agent, define a mandate, follow its activity, and intervene.

Tako’s proposed answer is a connected product built around a narrow trust boundary. Agent software may propose actions; it does not decide the extent of its own permissions. Confidential execution protects specified computation and state. Independent enforcement determines whether an action is authorized. Evaluation and disclosure help people decide whether an agent deserves that authority in the first place.

03 / One network, distinct responsibilities

Tako Runtime is the trust layer. The proposed runtime service, takod, runs measured agent versions, manages protected state and credential access, and produces typed action requests. Destination-chain executors enforce the financial boundary independently of the agent and its host.

Tako Terminal is the human and capital layer: the intended place to discover markets, test and fund agents, set their mandates, monitor activity, and intervene. It is also a distribution surface for developers and the place where performance history and user relationships can accumulate. Market discovery and research provide the first useful entry points into this experience.

Tako Market is the execution and liquidity layer. The intended progression begins with approved external venue adapters; crossing compatible flow internally is a later possibility with additional security requirements. Costs, finalized outcomes, and the limits of each supported venue should be visible to the person granting authority.

Tako Network is the whole: humans, capital, agents, developers, node providers, services, and markets connected through these layers. Read-only discovery and research can ship before financial execution. Runtime enforcement and recovery must be proven before an agent is given customer capital; the broader network remains the product vision.

Agent Studio supports this stack with creation, evaluation, observability, and governed improvement. The proposed Funding Rail brings human capital toward bounded agent accounts, initially with USDC on Arc. Funding, account access, and financial execution will be introduced in stages as their integrations are validated.

Trading, lending, borrowing, yield strategies, treasury, and paid research are applications of the same network. Tako Missions is one proposed product within Terminal: people or agents commission defined research, inspect the deliverable, and pay for accepted work. It does not replace the network, Terminal, Runtime, or Market. Shared identity, budgets, evaluation, and records should connect these products without letting a research payment authorize a trade or debt position.

04 / Why launch on Arc

Arc gives Tako a settlement foundation organized around stablecoin finance. USDC pays Arc gas as well as application transfers, so a user can budget capital and onchain operating costs in the same asset. This simplifies the intended funding experience; it does not make transactions free or guarantee fixed costs. Arc documents deterministic finality under its consensus assumptions, which can shorten the wait before a finalized action is reconciled. Settlement finality does not establish that a trade was profitable or a research result was correct. Stablecoin model, finality.

Arc's agent documentation describes ERC-8004 identity and reputation and ERC-8183 jobs with escrow, deliverables, evaluation, and settlement. These can connect Tako agents to other services and support paid research. Tako remains responsible for version binding, capital mandates, evidence quality, recovery, and the executor checks. Registration is not a security audit, feedback is not verified performance, and a paid job does not prove the truth of its output. These adapters require pinned contracts and interfaces; the standards and tutorial deployments must be checked separately. Agentic economy.

Our first agent integration follows Arc's ERC-8004 registration tutorial on Arc Testnet: publish an agent profile, register its identity, and connect external feedback to inspectable work. Tako will distinguish registration, feedback, and validation from its own evaluation record. Testnet registry addresses must not be reused as assumed mainnet deployments. Register an AI agent.

Arc's agentic-economy blueprint describes agents paying for data, services, and completed work through programmable stablecoin settlement. For Tako, this suggests a path from research agents to paid Missions and, later, agents that coordinate within separate spending mandates. These are product directions, not a claim that the integrations are already running. Arc Blueprints.

Circle's App Kit, CCTP, and Gateway offer possible funding and payment integrations. Support must be verified for each network, asset, and operation before it appears in Tako. A unified balance interface does not create a globally atomic spending limit across chains. Local grants remain authoritative. The reviewed App Kit matrix now lists Arc support for Send, Bridge, Swap, Unified Balance, Onramp, and Earn. Each integration still needs environment-specific validation; this list does not prove liquidity for an arbitrary asset. App Kit support.

On 16 September 2026, Arc's connection guide publishes both mainnet (chain ID 5042) and testnet (5042002), following the announced public-mainnet date. Tako's read-only discovery work targets Arc mainnet data. Agent identity and initial financial execution are tested separately on Arc Testnet; customer accounts require verified production configuration and Tako's own delivery gates. Arc connection guide, mainnet announcement.

05 / From an idea to a bounded action

An agent begins as a specification: its objective, software, model and tool configuration, data access, and evaluation requirements. Studio is intended to let templates, composable workflows, and code-based agents converge on the same versioned format.

A RuntimeVersion identifies an immutable approved software version. A Deployment describes a particular instance. A human or organization creates a Grant for the relevant destination chain, defining the permitted capabilities and their limits. Approval is tied to an identified version and scope, not to every future program with the same agent name.

The intended execution sequence is:

• Create and evaluate a candidate agent version against a defined workload and risk envelope.
• Deploy an approved version under an explicitly disclosed attestation and provider trust mode.
• Authorize narrow capabilities through a human-controlled Grant, including applicable amounts, recipients, venues, time limits, and fee constraints.
• Let the agent propose an action; takod constructs and signs a typed ActionIntent, not arbitrary caller-selected bytes.
• Have the destination-chain TakoExecutor independently validate the Grant, version binding, freshness, and complete capability-specific calldata before execution.
• After chain finality, record the actual outcome in an ExecutionJournal and reconcile the agent’s next state.

Arc is the canonical home and initial execution destination. This replaces the earlier Base launch plan. Additional EVM destinations require their own local executors and local authority. A chain is not supported merely because it is EVM-compatible: deployment, adapter validation, and conformance tests must precede that claim. Cross-chain transport must not become a way to silently expand a Grant.

Arc's USDC native interface uses 18 decimals and its ERC-20 interface uses 6; both address one underlying balance. Tako must preserve integer precision, charge both paths against the same economic spending limit, retain a gas reserve, and avoid counting the balance or transfer events twice. These are deployment requirements, not a completed migration. Arc integration differences.

06 / Authority, failure, and recovery

Agent code must never receive the user’s recovery key or the raw financial runtime signer. High-value bearer credentials are intended to remain behind a confined request proxy rather than being copied into arbitrary agent code. A model’s tool request is input to validation, not authorization by itself.

The destination executor must inspect the complete meaning of an allowed action. An allowlisted router address or selector alone is insufficient if nested calldata can redirect funds, create approvals, or invoke a different capability. Generic routers, multicalls, bridges, and similar surfaces require explicit validators before they can be supported.

Each action is bound to its destination and applicable authority and must satisfy replay protection and deadlines. A validly accepted action that fails in a downstream call consumes its action nonce while the downstream asset effects roll back. This distinction prevents an already accepted request from being reused as if nothing happened. Rejected authorization must not be confused with downstream execution failure.

A signed proposal cannot prove a completed trade. Pre-execution ActionIntent records and post-finality ExecutionJournal records have separate roles. The design includes pending-action locking and reconciliation to prevent concurrent instances or stale state from producing conflicting histories. Recovery must explicitly record any continuity gap rather than presenting an interrupted history as complete.

Revocation, expiry, and owner recovery are essential boundaries, not optional interface features. Revoking a Grant can stop future authorized activity; it cannot reverse transactions that have already finalized or eliminate an existing market position’s risk. Contract checks enforce defined constraints, not profitability or the truth of every input.

07 / Privacy and the trust model

The guiding principle is: private while acting, verifiable after, public by choice. This is a design objective with specific limits, not a promise that all activity is invisible.

Confidential compute is intended to protect covered code, secrets, and state from the host under the chosen hardware and attestation assumptions. It does not automatically hide ordinary EVM transactions, transfers, counterparties, timing, or public calldata. Private settlement would require a separate implemented and reviewed mechanism.

An external model, tool, RPC endpoint, or venue sees the information sent to it. Context selection and credential confinement can reduce exposure, but a confidential runtime cannot undo disclosure to an external service. TEE vulnerabilities, software defects, malicious dependencies, availability failures, and metadata leakage remain relevant risks.

Arc's planned Privacy Sector could complement Tako Runtime: Runtime protects the agent's offchain computation, while a reviewed Arc privacy integration could protect selected onchain state and transaction data. The current Arc documentation says privacy is not yet available. Tako's initial Arc actions therefore use the public EVM. Private execution, disclosure policies, recovery, and metadata leakage need a separate implemented and reviewed adapter before any settlement-privacy claim. Arc opt-in privacy.

The initial proposed trust mode is operator-attested AWS Nitro with contracts on Arc Testnet. The operator’s registrar, KMS, storage, attestation process, Arc validator assumptions, and RPC dependencies must be disclosed. This phase is not a decentralized or trustless network. On-chain-verifiable attestation, multiple providers, and stronger key-management arrangements are later delivery gates, not current guarantees. Arc's consensus does not attest Tako's offchain agents on Tako's behalf.

08 / Evaluation and governed learning

Studio is intended to capture a useful trajectory of each run: selected context and its provenance, model and tool interactions, costs, proposed actions, policy decisions, and finalized economic outcomes. Private details need access controls; public performance needs enough methodology to be interpreted honestly.

Evaluation must distinguish a hand-authored illustration, historical simulation, forward paper execution, and live trading. A headline return is incomplete without the time period, capital assumptions, drawdown, transaction costs, failed actions, and selection methodology. Paper performance is not a forecast and must not be presented as verified live performance.

On 7 September 2026, Flow v0 passed an initial historical evaluation: chronological training and validation followed by two sealed days, capacity-limited shared cash, delayed execution, modeled costs, daily checks, and removal of the best trade. It returned 53.21%; Rebound lost 5.85% and was rejected. A later Rotation hypothesis returned 32.16% retrospectively. A falsification baseline then entered every launch after ten swaps with the same exit and returned 74.09%, above both filtered agents; Flow and Rotation also selected substantially overlapping tokens. The current evidence therefore supports a historically profitable rotation and exit engine, not proven selection alpha or two independent agents. A forward paper comparison on newly indexed data is required.

A later multi-policy lab treats trading as a repeated game rather than a runner-prediction task. It searched 406 combinations across early activity, bursts, liquidity expansion, sell absorption, pullback recovery, and persistent strength. Early, Absorption, and Survivor policies stayed positive under a harsh historical execution test; Burst, Liquidity, and Reclaim did not. A first wallet-copy replay was also added. These are retrospective candidates for one coordinated forward-paper desk, not verified live agents or promised returns.

The first Tako Agent Arena extends that work into a forward experiment. It generates 256 agents with different entries, exits, holding periods, and risk sizes, then gives each agent the same live on-chain events and a separate paper wallet. A minimum trade count and drawdown-aware leaderboard prevent a few lucky trades from being presented as a winner. This arena is an evaluation system, not a live fund: promotion requires longer forward evidence, harsher execution checks, a baseline comparison, and explicit human authority before any bounded real-capital test.

These earlier experiments retain their original datasets, chains, dates, and limitations. They are not Arc performance records. An Arc candidate must be evaluated again against Arc data, actual supported venues, quotes, fees, liquidity, and execution failures before any capital-readiness claim.

The learning plane is proposed to collect production observations and produce candidate improvements offline. A changed policy, prompt, model configuration, or agent implementation must pass the applicable evaluation and release process. A replacement version does not silently inherit the previous version’s capital authority: the owner must opt in through the required approval and Grant changes.

This separation lets agents improve without allowing a self-modifying process to decide what a user has authorized. It also makes comparisons and rollbacks meaningful: people can identify which approved version produced a result.

09 / Participation and economics

The intended participants have different responsibilities. Developers publish and maintain software. Users and organizations choose mandates and capital limits. Providers supply execution capacity under disclosed trust modes. Model, data, tool, and venue operators supply optional services. These roles should remain visible even when the Terminal combines them into one workflow.

Potential business models include Studio workspaces and evaluation, runtime compute and managed services, and fees associated with execution or distribution in Tako Market. These are design directions, not announced prices, existing revenue, or commitments to any fee schedule. Model usage, data, tools, gas, slippage, and provider charges should be visible alongside any platform fee. Agent actions must respect the applicable authorized fee bounds.

The Arc launch plan uses USDC for initial account funding and proposed protocol settlement. A Missions fee would pay for defined work under disclosed acceptance and refund terms. Trading P/L, research revenue, compute charges, platform fees, and gas must remain separate accounting categories. USDC denomination does not remove issuer, transfer restriction, bridge, liquidity, or operational risks.

This paper proposes no token sale, token allocation, staking yield, guaranteed return, or entitlement to protocol revenue. Any future economic mechanism would require its own explicit design and disclosures. Proposed actions, paper activity, and finalized real execution must be counted separately.

10 / Roadmap and release status

The build sequence in simple steps:

• Step 1 — Launch the website and whitepaper. Establish Tako's identity, show the Terminal direction, and publish the roadmap at takoterminal.xyz.
• Step 2 — Deliver useful token investigations in Terminal. Verify one Arc venue and reconstruct its actual trading activity through RPC. Give a versioned research agent bounded tools to investigate a supported token's early buyers and subsequent sales. Show transaction evidence, attribution uncertainty and historical coverage. Connect a funded model provider and enforce usage limits. The raw contract/mint feed supports this work; it is not the completed product.
• Step 3 — Keep investigations running and prove paid delivery. Persist watchlists, compare observations, and show meaningful updates while the user is away. Introduce clearly priced USDC research payments and the same capability as an agent-callable API after verifying delivery, payment, identity and failure/refund handling. Validate with independent buyers. The ERC-8004 tutorial currently targets Arc Testnet; registry feedback and payment volume alone do not establish work quality.
• Step 4 — Open Agent Studio and paper testing. Let people create and train agents, compare strategies on fresh data, and inspect losses, costs, and decisions before allocating real capital. Keep paper results separate from live records.
• Step 5 — Add accounts and bounded execution. Prove USDC accounting, permissions, payment limits, revocation, recovery, and the confidential runtime on Arc Testnet. Validate a venue before adding swaps. Begin a limited mainnet pilot only after the security and operational gates pass.
• Step 6 — Expand the network. Add lending, borrowing, and yield agents across validated chains and protocols, with separate capability controls and local authority. Enable developer distribution, additional research Missions, providers, and reviewed cross-chain funding. Add Arc privacy only after it becomes available and Tako's integration is tested.

Current implementation scope: the production website build contains the landing page and whitepaper, with a clearly labeled Terminal preview; replacement public hosting is being selected. Arc discovery runs locally using Arc RPC only. It scans ERC-20-shaped mint events within a bounded block window and reads contract code, metadata, supply, and block timestamps. It identifies a new contract only when preceding-block bytecode was absent; a mint alone is not a launch. This is not a complete launch index, and no external price, liquidity, or holder feed is used. The research execution loop, persistent monitoring and paid service are not implemented yet. Earlier agent screens contain illustrative and paper activity and remain local development experiments. Customer capital accounts, autonomous trading, the confidential runtime and network settlement are later releases. Website publication does not imply those services are available.

Financial execution has additional release gates:

• Establish the protocol invariants and test coverage, then the operator-attested Arc Testnet runtime slice. The runtime specification defines 24 core Phase 0 acceptance tests plus Arc integration requirements; the learning plane has separate gates.
• Verify Arc network identity, deployed bytecode, native/ERC-20 USDC accounting, gas handling, finality, revocation, recovery, and one narrow payment capability. Add a swap only after validating its actual venue and quote path.
• Prepare Arc mainnet release with verified production addresses, independent security review, operational monitoring, and explicit user authority. Testnet balances and examples never become production defaults automatically.
• Add on-chain-verifiable attestation and the required security review before presenting a stronger verification claim.
• Admit external developers through a controlled alpha with usable deployment, debugging, costs, and evaluation workflows.
• Validate approved multi-provider operation, stronger key management, and a second destination EVM before claiming those capabilities.
• Introduce Tako Market execution and capital workflows only after their runtime, venue, accounting, and security prerequisites are met.
• Expand toward open provider participation and stronger privacy only with the corresponding implementation and adversarial evidence. Arc Privacy Sector is a candidate integration after availability and review, not a prerequisite for Tako's public-EVM prototype.

The roadmap advances on demonstrated functionality and security, rather than dates alone. Paid research, trading authority, and recovery remain separate permissions. Neither a launch announcement nor an agent registration replaces those requirements.

11 / Risks and release status

Financial agents can make poor decisions, markets can move against a strategy, and software or protocol failures can affect funds. Spending limits, testing, and monitoring help manage these risks but cannot eliminate them.

This whitepaper describes the network Tako is building. The release roadmap distinguishes current availability from planned capabilities, and each financial integration will identify its supported chains, protocols, and operating limits before users can grant it authority.