Build an L3 Appchain in 2026 with Open-Source Boilerplates

Choose your L2 settlement layer

Your L2 settlement layer determines which L3 appchain boilerplates are available and compatible. This decision dictates your execution environment, data availability costs, and the tooling ecosystem you can leverage. Starknet and Arbitrum represent the two primary paths, each with distinct architectural implications for your L3.

Starknet

Starknet uses STARK-based zero-knowledge proofs, offering high throughput and a Cairo programming language for L3 execution. If you choose Starknet, you will likely use frameworks like Spire or Kakarot to deploy your L3. These boilerplates are optimized for Cairo, meaning your smart contracts must be written in or compiled to Cairo.

Starknet’s native data availability is handled via blob space, which can be cheaper than calldata-heavy L2s for certain workloads. However, the ecosystem is younger, and the developer experience requires familiarity with Cairo’s constraints. If your team lacks Cairo expertise, the learning curve may outweigh the initial cost benefits.

Arbitrum

Arbitrum relies on optimistic rollup technology, using fraud proofs to secure the chain. This approach allows for EVM equivalence, meaning you can deploy standard Solidity smart contracts on your L3 without modification. Tools like Arbitrum Orbiter or custom rollup configurations allow you to spin up an L3 that feels identical to Ethereum mainnet but with lower fees.

The Arbitrum ecosystem is mature, with extensive documentation and a larger pool of developers familiar with Solidity. Data availability costs can be higher than Starknet’s blob space if you rely heavily on calldata, but the flexibility of EVM compatibility often simplifies migration from existing dApps. If your priority is rapid deployment of existing Solidity code, Arbitrum is the safer bet.

Decision Criteria

Select the L2 that aligns with your team’s technical stack. If you are building a new dApp from scratch and need maximum throughput with lower DA costs, Starknet is compelling. If you are porting an existing EVM-based application and value ecosystem maturity, Arbitrum is the logical choice.

Fork the open-source boilerplate

To build an L3 appchain, you start by cloning a repository that already handles the heavy lifting: sequencer logic, data availability, and L2 settlement proofs. Instead of writing a full stack from scratch, you pick a boilerplate tailored to your target L2—such as Starknet or Spire—and configure it to your specific execution environment.

This approach mirrors how you might use a web framework like Next.js or a blockchain framework like Foundry. You get a working prototype instantly, allowing you to focus on the unique state transitions and business logic of your application rather than consensus mechanics.

1. Clone the repository

Begin by cloning the boilerplate repository relevant to your chosen L2. For Starknet, you might use a framework like Pylons or a Starknet-specific rollup template. For Spire, use their official appchain starter. Clone the repo to your local development environment to ensure you have the correct version of the codebase.

# Example for a generic L3 boilerplate
git clone https://github.com/<provider>/<boilerplate-name>.git
cd <boilerplate-name>

2. Install dependencies

Once the repository is cloned, install the necessary dependencies. Most modern L3 boilerplates use Rust, Go, or TypeScript for the sequencer and node components. Run the standard package manager command for your language to fetch all libraries. This step ensures your local environment has the correct versions of cryptographic libraries and networking tools required to interface with the L2.

# For Rust-based rollups
cargo build --release

# For TypeScript/Node-based nodes
npm install

3. Configure L2 RPC endpoints

The most critical configuration step is setting up the connection to your L2 settlement layer. Open the configuration file (often .env or config.toml) and input your L2 RPC endpoint. This allows your L3 sequencer to read the latest block data and submit proofs or state roots back to the L2 contracts. Ensure your RPC provider has sufficient throughput to handle the polling frequency your sequencer requires.

# config.toml example
[L2]
rpc_url = "https://starknet-mainnet.public.blastapi.io"
chain_id = "SN_SEPOLIA"

4. Run the local node

With dependencies installed and the RPC endpoint configured, start the local node. This launches the sequencer, which begins accepting transactions and building blocks. Monitor the logs to verify that the node is successfully syncing with the L2. If you see errors related to block finality or RPC timeouts, double-check your L2 endpoint and network connectivity.

# Start the sequencer and node
npm run start
# or
cargo run --release

By following these steps, you have a functional L3 appchain running locally. You can now begin integrating your application's smart contracts or state machines into the sequencer's execution layer, testing your specific logic against a real L2 settlement environment.

Integrate DevRel kits for adoption

Third-party developers won’t build on your L3 appchain if they have to reverse-engineer your infrastructure. You must provide standardized DevRel kits that abstract away the complexity of the underlying rollup architecture. By offering pre-built documentation templates, SDK wrappers, and streamlined onboarding flows, you lower the barrier to entry and shift focus from infrastructure setup to application logic.

Standardize API and SDK Wrappers

Raw RPC endpoints are insufficient for rapid development. Instead of exposing raw Starknet or Spire node interfaces, wrap them in language-specific SDKs that handle serialization, gas estimation, and transaction signing. These wrappers should mirror the intuitive feel of popular web2 frameworks while maintaining the security guarantees of the L3.

For example, provide TypeScript and Python SDKs that include typed error handling for common L3-specific issues, such as sequencer downtime or L2 settlement delays. This reduces the cognitive load for developers who are used to predictable API responses. Include clear examples for connecting to your testnet, submitting transactions, and listening to events.

Provide Documentation Templates

Documentation is often the first point of contact for new developers. Use standardized templates that cover the essential integration steps: environment setup, dependency installation, and a "Hello World" transaction. Avoid generic explanations; instead, provide concrete code snippets that work out of the box.

Reference how Starknet and Spire structure their docs. Starknet’s documentation is effective because it separates the "what" from the "how," allowing developers to quickly find the specific contract interaction they need. Spire’s approach of providing clear, copy-pasteable configuration files for different networks (mainnet, testnet, devnet) is equally valuable. Ensure your templates are version-controlled and updated with every release.

Streamline Onboarding Flows

The first 15 minutes of a developer’s experience determine whether they stay. Automate the initial setup process by providing a CLI tool or a GitHub template repository that scaffolds a complete project structure. This should include:

• Pre-configured hardhat.config or foundry.toml files pointing to your L3 RPC.
• A sample smart contract with a corresponding test suite.
• A pre-funded testnet faucet integration for immediate testing.

By removing the friction of configuration, you allow developers to validate their ideas quickly. This accelerates the feedback loop and encourages more robust community contributions.

Test the chain before mainnet

Before pushing your L3 appchain to production, you must verify that the settlement layer remains intact under load. An L3 inherits its security from the underlying L2, so a bug in your rollup logic can corrupt the state root submitted to the L2. This section covers the validation phase: ensuring transactions settle correctly and edge cases do not break the chain.

Run a local fork test

Spin up a local node connected to the target L2 testnet (e.g., Starknet Sepolia). Use your boilerplate’s configuration to point the L3 sequencer to this testnet. Submit a batch of transactions that mimic your core application logic. Verify that the L2 sees the correct state updates. If you are using a shared sequencer, confirm that the sequencing service correctly batches your L3 blocks before sending them to the L2.

Verify settlement integrity

Check that the data availability and state commitments match your expectations. For Starknet-based L3s, this means validating that the SNARK proofs or data blobs submitted to the L2 are valid. Use tools like starknet-devnet or starknet-foundry to simulate the proving process locally. If the proof fails locally, it will fail on-chain, wasting gas and potentially stalling your chain.

Test edge cases

Force failure conditions to see how your L3 handles them. What happens if a sequencer goes offline? Does the L2 revert the state, or does it leave the chain in a broken state? Test with large payloads, empty blocks, and rapid state changes. Your goal is to ensure that the L2 never accepts an invalid state transition.

Common L3 setup mistakes

Boilerplate code accelerates deployment, but it also hides configuration traps. When building an L3 appchain on Starknet or similar L2s, generic templates often assume default settlement parameters that break under real load. The most frequent failures occur in sequencer configuration and gas token handling.

Sequencer misconfiguration is the leading cause of downtime. Many templates leave the sequencer in a "local" mode by default, which skips the fault-proof verification step. If you do not explicitly enable the sequencer to submit batches to the L2 verifier, your chain will process transactions locally but fail to settle. This creates a "zombie chain" where users see balances, but the state is invalid on the L2. Always verify that your sequencer is pointed to the correct L2 entry points and that the submission_interval is set to match your L2's block time.

Incorrect L2 gas token settings cause immediate transaction failures. An L3 inherits the security of its L2, but it must pay for that security using the L2's native currency (e.g., ETH on Ethereum L2s). Boilerplates often default to using the L3's native token for gas, which is incorrect. If your L3 tries to pay for L2 data availability with its own token, the L2 verifier will reject the batch. You must configure your L3 to hold a reserve of the L2's native token and route gas payments accordingly.

A similar error appears in state root synchronization. Some templates assume synchronous reading of L2 data is sufficient. As shown in Spire’s demo, relying on synchronous reads without proper retry logic for L2 finality can cause your L3 to process "reorged" or pending transactions as final. Ensure your L3 validator waits for the L2 block to be considered final before committing state to the L3.

Frequently asked: what to check next

Work through 2026 Guide: Accelerating L3 Appchain Adoption with Open-Source Boilerplates and DevRel Kits

1

Gather what you need

Confirm the materials, tools, account access, or setup pieces for 2026 Guide: Accelerating L3 Appchain Adoption with Open-Source Boilerplates and DevRel Kits before changing anything.

2

Work in order

Complete one step at a time and verify the result before moving on. Most failed guides get confusing when two changes happen at once.

3

Check the finished result

Compare the outcome with the expected shape, connection, texture, or behavior, then adjust only the part that is actually off.

Previous

123

Next