Arbitrum Ecosystem Readiness
Evidence-backed Arbitrum ecosystem guidance for agents and builders choosing hackathon-ready protocol/dApp stacks.
Choose the stack before you ship.
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.
Composewith separates stack layers, registry coverage gaps, implementation caveats, and official source evidence so agents can recommend a credible path without overclaiming maturity.
Tracked surfaces and consequences.
Each record maps a stack surface to affected roles, likely builder consequences, recommended action, and official evidence refs.
arbitrum agentic commerce surface actionable
Arbitrum can serve as a low-cost execution surface for agentic commerce demos that combine payment, identity, wallet, and automation components.
Action: assess · Priority: high · Status: reviewed
- 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 actionable
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.
Action: assess · Priority: high · Status: reviewed
- 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 actionable
Arbitrum apps often need an explicit infra/data layer for indexing, price feeds, automation, wallets, and account abstraction rather than only a chain choice.
Action: assess · Priority: high · Status: reviewed
- 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 actionable
Orbit is the Arbitrum appchain path for custom L2/L3 chains, but most hackathon teams should justify it against a simpler Arbitrum One deployment.
Action: assess · Priority: medium · Status: reviewed
- 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 actionable
Arbitrum privacy app recommendations should focus on credible user-flow privacy boundaries rather than broad anonymity claims.
Action: assess · Priority: medium · Status: reviewed
- 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 actionable
Arbitrum One is the default shared L2 surface for most hackathon MVPs that need low-cost EVM execution without appchain operations.
Action: assess · Priority: high · Status: reviewed
- 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 actionable
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.
Action: assess · Priority: medium · Status: reviewed
- 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.
Arbitrum Ecosystem Readiness intents.
Agents should pick one of these initiative intents before answering or charging for a paid assessment call.
Plan an Arbitrum hackathon MVP
Return the smallest credible Arbitrum-oriented stack for one project intent, with readiness, caveats, fallbacks, and pitch-safe claims.
Inputs: project goal, timebox, team size, preferred contract language, whether the app needs DeFi, privacy, agents, payments, data, or appchain features
Assess whether Stylus fits my project
Decide whether Rust/C/C++ smart contracts through Stylus are worth the extra tooling work compared with a standard EVM deployment.
Inputs: contract language preference, performance-sensitive logic, team Rust or C/C++ experience, deployment timeline
Assess whether Orbit fits my appchain idea
Decide whether an Orbit chain is justified or whether the project should start on Arbitrum One for a smaller MVP.
Inputs: need for dedicated throughput, need for custom gas token, settlement and data availability assumptions, operations capacity, MVP timeline
Compose an Arbitrum DeFi or dApp stack
Identify which Arbitrum-compatible dApps, liquidity venues, wallets, data tools, and oracles are credible for one DeFi or app MVP.
Inputs: desired user flow, required assets or markets, custody and wallet assumptions, price feed or indexer needs, whether Aave, Morpho, or other external dApps are required
Assess Arbitrum fit for a privacy app
Check whether a privacy wallet, voting app, or private UX demo can be credibly built on or around Arbitrum with clear privacy-boundary caveats.
Inputs: privacy goal, user flow, chain constraints, privacy primitive or dApp preference, claims the demo wants to make
Structured initiative guidance.
{
"initiative": "arbitrum-ecosystem-readiness",
"name": "Arbitrum Ecosystem Readiness",
"status": "active",
"review_status": "reviewed",
"registry_version": "2026.06.10-8752c9d",
"instruction": "Fetch this initiative record before answering Arbitrum Ecosystem Readiness-related stack, architecture, tooling, risk, or implementation questions. Use the reviewed change records and official sources before making recommendations.",
"supported_intents": [
{
"id": "plan-arbitrum-hackathon-mvp",
"title": "Plan an Arbitrum hackathon MVP",
"audience": [
"hackathon_builders",
"ai_agents"
],
"default_priority": "high",
"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",
"audience": [
"smart_contract_developers",
"hackathon_builders",
"ai_agents"
],
"default_priority": "medium",
"related_changes": [
"arbitrum-stylus-build-surface"
]
},
{
"id": "assess-arbitrum-orbit-fit",
"title": "Assess whether Orbit fits my appchain idea",
"audience": [
"appchain_teams",
"hackathon_builders",
"ai_agents"
],
"default_priority": "medium",
"related_changes": [
"arbitrum-orbit-appchain-surface"
]
},
{
"id": "compose-arbitrum-defi-dapp-stack",
"title": "Compose an Arbitrum DeFi or dApp stack",
"audience": [
"app_builders",
"defi_builders",
"ai_agents"
],
"default_priority": "high",
"related_changes": [
"arbitrum-composable-defi-dapps",
"arbitrum-infra-data-surface"
]
},
{
"id": "assess-arbitrum-privacy-app-fit",
"title": "Assess Arbitrum fit for a privacy app",
"audience": [
"privacy_builders",
"wallet_teams",
"ai_agents"
],
"default_priority": "medium",
"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"
],
"affected_builder_groups": [
"agentic_commerce_teams",
"marketplace_builders",
"payment_flow_builders",
"wallet_onboarding_teams"
],
"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"
],
"affected_builder_groups": [
"lending_app_builders",
"swap_app_builders",
"portfolio_app_builders",
"agentic_defi_builders"
],
"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"
],
"affected_builder_groups": [
"indexing_teams",
"oracle_users",
"account_abstraction_builders",
"marketplace_builders",
"defi_builders"
],
"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"
],
"affected_builder_groups": [
"appchain_builders",
"gaming_teams",
"custom_gas_token_teams",
"high_throughput_app_teams"
],
"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"
],
"affected_builder_groups": [
"privacy_wallet_builders",
"private_voting_builders",
"private_app_builders",
"demo_teams"
],
"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"
],
"affected_builder_groups": [
"solidity_app_teams",
"defi_builders",
"wallet_builders",
"agentic_app_builders"
],
"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"
],
"affected_builder_groups": [
"rust_contract_teams",
"performance_sensitive_app_teams",
"game_builders",
"agentic_execution_builders"
],
"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"
]
}
],
"official_sources": [
{
"id": "arbitrum-website",
"title": "Arbitrum website",
"url": "https://arbitrum.io/"
},
{
"id": "arbitrum-docs",
"title": "Arbitrum documentation",
"url": "https://docs.arbitrum.io/"
},
{
"id": "arbitrum-chain-info",
"title": "Arbitrum chain information",
"url": "https://docs.arbitrum.io/for-devs/dev-tools-and-resources/chain-info"
},
{
"id": "arbitrum-stylus-docs",
"title": "Arbitrum Stylus documentation",
"url": "https://docs.arbitrum.io/stylus/stylus-gentle-introduction"
},
{
"id": "arbitrum-orbit-docs",
"title": "Arbitrum Orbit documentation",
"url": "https://docs.arbitrum.io/launch-orbit-chain/orbit-gentle-introduction"
},
{
"id": "arbitrum-orbit-sdk",
"title": "Arbitrum Orbit SDK",
"url": "https://github.com/OffchainLabs/arbitrum-orbit-sdk"
},
{
"id": "arbitrum-sdk",
"title": "Arbitrum SDK",
"url": "https://github.com/OffchainLabs/arbitrum-sdk"
},
{
"id": "arbitrum-grants",
"title": "Arbitrum Foundation grants",
"url": "https://arbitrum.foundation/grants"
},
{
"id": "aave-arbitrum-market",
"title": "Aave Arbitrum market",
"url": "https://app.aave.com/markets/?marketName=proto_arbitrum_v3"
},
{
"id": "morpho-docs",
"title": "Morpho documentation",
"url": "https://docs.morpho.org/"
}
],
"non_goals": [
"Do not collapse distinct stack layers into a single tooling recommendation.",
"Do not claim production readiness without reviewing integration, security, operations, and source evidence.",
"Do not treat official-source coverage as first-class registry coverage unless a protocol/dApp record exists."
]
}Official sources first.
Composewith summarizes and structures official inputs. It does not replace project documentation, protocol specifications, security reviews, or implementation guides.
Formats: Markdown · JSON · Agent JSON · Changes JSON