# Arbitrum Ecosystem Readiness

> Evidence-backed Arbitrum ecosystem guidance for agents and builders choosing hackathon-ready protocol/dApp stacks.

- Status: active
- Review status: reviewed
- Last verified: 2026-06-09

## Why it matters

Arbitrum builders need more than a generic L2 recommendation. Agents should understand when to use Arbitrum One, when Orbit is justified, when Stylus is worth the extra tooling work, which infrastructure surfaces are needed, and where composable dApps such as DeFi protocols may fit a credible MVP.

## Candidate change areas

### arbitrum agentic commerce surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Arbitrum can serve as a low-cost execution surface for agentic commerce demos that combine payment, identity, wallet, and automation components.
- Possible consequences:
  - Agents should separate the execution chain choice from payment protocol and agent identity/discovery choices.
  - x402 should be treated as a payment layer, while ERC-8004 should be treated as agent identity/discovery/reputation/validation infrastructure.
  - Builders should not imply ERC-8004 is a chain or that 8004scan is chain ID 8004.

### arbitrum composable defi dapps
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Arbitrum stack plans should account for composable DeFi and dApp dependencies such as Aave, Morpho, Uniswap, and other liquidity venues when the user flow needs them.
- Possible consequences:
  - Agents should ask whether the project needs lending, borrowing, vaults, swaps, pricing, liquidation data, or portfolio state before choosing dApps.
  - Aave and Morpho should be added as first-class registry records before Composewith makes detailed readiness claims about them.
  - Until coverage is added, agents should cite official Aave/Morpho sources directly and label them as registry coverage gaps.

### arbitrum infra data surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Arbitrum apps often need an explicit infra/data layer for indexing, price feeds, automation, wallets, and account abstraction rather than only a chain choice.
- Possible consequences:
  - Agents should include indexer/oracle/wallet/automation requirements in Arbitrum stack plans when the user flow depends on them.
  - Builders should cite official support for the specific chain and data source they use.
  - A low-cost L2 recommendation is incomplete if the demo cannot read the data or trigger the actions it claims to support.

### arbitrum orbit appchain surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: medium
- Summary: Orbit is the Arbitrum appchain path for custom L2/L3 chains, but most hackathon teams should justify it against a simpler Arbitrum One deployment.
- Possible consequences:
  - Agents should ask about operations capacity, data availability assumptions, custom gas token needs, and bridge/RPC/sequencer plans before recommending Orbit.
  - For a 48-hour MVP, Orbit should usually be a demo architecture or explicit appchain track choice, not an accidental default.
  - Builders need a fallback plan that starts on Arbitrum One if chain operations are outside the timebox.

### arbitrum privacy app surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: medium
- Summary: Arbitrum privacy app recommendations should focus on credible user-flow privacy boundaries rather than broad anonymity claims.
- Possible consequences:
  - Agents should check whether a privacy protocol/dApp actually supports the intended Arbitrum chain before recommending it as an implementation dependency.
  - For hackathon demos, mocked or offchain privacy flows should be labeled clearly if production integration is not complete.
  - README and pitch copy should include do-not-claim guidance for anonymity, unlinkability, and production security.

### arbitrum shared l2 build surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Arbitrum One is the default shared L2 surface for most hackathon MVPs that need low-cost EVM execution without appchain operations.
- Possible consequences:
  - Agents should usually choose Arbitrum One before recommending Orbit for a small MVP.
  - Builders can preserve standard EVM tooling while targeting lower-cost execution than Ethereum mainnet.
  - Bridge, sequencer, and chain-specific support assumptions should still be stated in README and pitch materials.

### arbitrum stylus build surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: medium
- Summary: Stylus is a credible Arbitrum build surface for Rust, C, and C++ contracts, but it should be selected for a reason rather than by default.
- Possible consequences:
  - Agents should recommend Stylus when the project benefits from non-Solidity languages, performance-sensitive logic, or reusable Rust/C/C++ code.
  - For simple ERC-20-style contracts or teams without Rust/C/C++ experience, standard EVM deployment is the safer hackathon path.
  - README claims should distinguish Stylus experimentation from audited production readiness.

## Initiative intents

- **Plan an Arbitrum hackathon MVP** (plan-arbitrum-hackathon-mvp) — Return the smallest credible Arbitrum-oriented stack for one project intent, with readiness, caveats, fallbacks, and pitch-safe claims.
- **Assess whether Stylus fits my project** (assess-arbitrum-stylus-fit) — Decide whether Rust/C/C++ smart contracts through Stylus are worth the extra tooling work compared with a standard EVM deployment.
- **Assess whether Orbit fits my appchain idea** (assess-arbitrum-orbit-fit) — Decide whether an Orbit chain is justified or whether the project should start on Arbitrum One for a smaller MVP.
- **Compose an Arbitrum DeFi or dApp stack** (compose-arbitrum-defi-dapp-stack) — Identify which Arbitrum-compatible dApps, liquidity venues, wallets, data tools, and oracles are credible for one DeFi or app MVP.
- **Assess Arbitrum fit for a privacy app** (assess-arbitrum-privacy-app-fit) — Check whether a privacy wallet, voting app, or private UX demo can be credibly built on or around Arbitrum with clear privacy-boundary caveats.

## Official sources

- [Arbitrum website](https://arbitrum.io/)
- [Arbitrum documentation](https://docs.arbitrum.io/)
- [Arbitrum chain information](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/chain-info)
- [Arbitrum Stylus documentation](https://docs.arbitrum.io/stylus/stylus-gentle-introduction)
- [Arbitrum Orbit documentation](https://docs.arbitrum.io/launch-orbit-chain/orbit-gentle-introduction)
- [Arbitrum Orbit SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk)
- [Arbitrum SDK](https://github.com/OffchainLabs/arbitrum-sdk)
- [Arbitrum Foundation grants](https://arbitrum.foundation/grants)
- [Aave Arbitrum market](https://app.aave.com/markets/?marketName=proto_arbitrum_v3)
- [Morpho documentation](https://docs.morpho.org/)

## What the agent receives

```json
{
  "initiative": "arbitrum-ecosystem-readiness",
  "name": "Arbitrum Ecosystem Readiness",
  "status": "active",
  "registry_version": "2026.06.10-8752c9d",
  "supported_intents": [
    {
      "id": "plan-arbitrum-hackathon-mvp",
      "title": "Plan an Arbitrum hackathon MVP",
      "related_changes": [
        "arbitrum-shared-l2-build-surface",
        "arbitrum-agentic-commerce-surface",
        "arbitrum-composable-defi-dapps",
        "arbitrum-infra-data-surface"
      ]
    },
    {
      "id": "assess-arbitrum-stylus-fit",
      "title": "Assess whether Stylus fits my project",
      "related_changes": [
        "arbitrum-stylus-build-surface"
      ]
    },
    {
      "id": "assess-arbitrum-orbit-fit",
      "title": "Assess whether Orbit fits my appchain idea",
      "related_changes": [
        "arbitrum-orbit-appchain-surface"
      ]
    },
    {
      "id": "compose-arbitrum-defi-dapp-stack",
      "title": "Compose an Arbitrum DeFi or dApp stack",
      "related_changes": [
        "arbitrum-composable-defi-dapps",
        "arbitrum-infra-data-surface"
      ]
    },
    {
      "id": "assess-arbitrum-privacy-app-fit",
      "title": "Assess Arbitrum fit for a privacy app",
      "related_changes": [
        "arbitrum-privacy-app-surface"
      ]
    }
  ],
  "changes": [
    {
      "id": "arbitrum-agentic-commerce-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "agent_builders",
        "hackathon_builders",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should separate the execution chain choice from payment protocol and agent identity/discovery choices.",
        "x402 should be treated as a payment layer, while ERC-8004 should be treated as agent identity/discovery/reputation/validation infrastructure.",
        "Builders should not imply ERC-8004 is a chain or that 8004scan is chain ID 8004."
      ],
      "evidence_refs": [
        "official:arbitrum-docs"
      ]
    },
    {
      "id": "arbitrum-composable-defi-dapps",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "defi_builders",
        "hackathon_builders",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should ask whether the project needs lending, borrowing, vaults, swaps, pricing, liquidation data, or portfolio state before choosing dApps.",
        "Aave and Morpho should be added as first-class registry records before Composewith makes detailed readiness claims about them.",
        "Until coverage is added, agents should cite official Aave/Morpho sources directly and label them as registry coverage gaps."
      ],
      "evidence_refs": [
        "official:aave-arbitrum-market",
        "official:morpho-docs",
        "official:arbitrum-docs"
      ]
    },
    {
      "id": "arbitrum-infra-data-surface",
      "type": "indexer_surface",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "app_builders",
        "data_engineers",
        "wallet_teams",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should include indexer/oracle/wallet/automation requirements in Arbitrum stack plans when the user flow depends on them.",
        "Builders should cite official support for the specific chain and data source they use.",
        "A low-cost L2 recommendation is incomplete if the demo cannot read the data or trigger the actions it claims to support."
      ],
      "evidence_refs": [
        "official:arbitrum-docs",
        "official:arbitrum-chain-info"
      ]
    },
    {
      "id": "arbitrum-orbit-appchain-surface",
      "type": "protocol_architecture",
      "status": "reviewed",
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "appchain_teams",
        "hackathon_builders",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should ask about operations capacity, data availability assumptions, custom gas token needs, and bridge/RPC/sequencer plans before recommending Orbit.",
        "For a 48-hour MVP, Orbit should usually be a demo architecture or explicit appchain track choice, not an accidental default.",
        "Builders need a fallback plan that starts on Arbitrum One if chain operations are outside the timebox."
      ],
      "evidence_refs": [
        "official:arbitrum-orbit-docs",
        "official:arbitrum-orbit-sdk"
      ]
    },
    {
      "id": "arbitrum-privacy-app-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "privacy_builders",
        "wallet_teams",
        "hackathon_builders",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should check whether a privacy protocol/dApp actually supports the intended Arbitrum chain before recommending it as an implementation dependency.",
        "For hackathon demos, mocked or offchain privacy flows should be labeled clearly if production integration is not complete.",
        "README and pitch copy should include do-not-claim guidance for anonymity, unlinkability, and production security."
      ],
      "evidence_refs": [
        "official:arbitrum-docs"
      ]
    },
    {
      "id": "arbitrum-shared-l2-build-surface",
      "type": "protocol_architecture",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "hackathon_builders",
        "app_builders",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should usually choose Arbitrum One before recommending Orbit for a small MVP.",
        "Builders can preserve standard EVM tooling while targeting lower-cost execution than Ethereum mainnet.",
        "Bridge, sequencer, and chain-specific support assumptions should still be stated in README and pitch materials."
      ],
      "evidence_refs": [
        "official:arbitrum-docs",
        "official:arbitrum-chain-info"
      ]
    },
    {
      "id": "arbitrum-stylus-build-surface",
      "type": "evm_capability",
      "status": "reviewed",
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "smart_contract_developers",
        "hackathon_builders",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should recommend Stylus when the project benefits from non-Solidity languages, performance-sensitive logic, or reusable Rust/C/C++ code.",
        "For simple ERC-20-style contracts or teams without Rust/C/C++ experience, standard EVM deployment is the safer hackathon path.",
        "README claims should distinguish Stylus experimentation from audited production readiness."
      ],
      "evidence_refs": [
        "official:arbitrum-stylus-docs"
      ]
    }
  ]
}
```

---
Canonical: https://composewith.eth/initiatives/arbitrum-ecosystem-readiness · JSON: https://composewith.eth/initiatives/arbitrum-ecosystem-readiness/index.json