-```
-
-## Directory Structure
-
-
-├── cannon: Onchain MIPS instruction emulator for fault proofs
-├── devnet-sdk: Comprehensive toolkit for standardized devnet interactions
-├── docs: A collection of documents including audits and post-mortems
-├── kurtosis-devnet: OP-Stack Kurtosis devnet
-├── op-acceptance-tests: Acceptance tests and configuration for OP Stack
-├── op-alt-da: Alternative Data Availability mode (beta)
-├── op-batcher: L2-Batch Submitter, submits bundles of batches to L1
-├── op-chain-ops: State surgery utilities
-├── op-challenger: Dispute game challenge agent
-├── op-conductor: High-availability sequencer service
-├── op-deployer: CLI tool for deploying and upgrading OP Stack smart contracts
-├── op-devstack: Flexible test frontend for integration and acceptance testing
-├── op-dispute-mon: Off-chain service to monitor dispute games
-├── op-dripper: Controlled token distribution service
-├── op-e2e: End-to-End testing of all bedrock components in Go
-├── op-faucet: Dev-faucet with support for multiple chains
-├── op-fetcher: Data fetching utilities
-├── op-interop-mon: Interoperability monitoring service
-├── op-node: Rollup consensus-layer client
-├── op-preimage: Go bindings for Preimage Oracle
-├── op-program: Fault proof program
-├── op-proposer: L2-Output Submitter, submits proposals to L1
-├── op-service: Common codebase utilities
-├── op-supervisor: Service to monitor chains and determine cross-chain message safety
-├── op-sync-tester: Sync testing utilities
-├── op-test-sequencer: Test sequencer for development
-├── op-up: Deployment and management utilities
-├── op-validator: Tool for validating Optimism chain configurations and deployments
-├── op-wheel: Database utilities
-├── ops: Various operational packages
-├── packages
-│ ├── contracts-bedrock: OP Stack smart contracts
-
-
-## Development and Release Process
-
-### Overview
-
-Please read this section carefully if you're planning to fork or make frequent PRs into this repository.
-
-### Production Releases
-
-Production releases are always tags, versioned as `/v`.
-For example, an `op-node` release might be versioned as `op-node/v1.1.2`, and smart contract releases might be versioned as `op-contracts/v1.0.0`.
-Release candidates are versioned in the format `op-node/v1.1.2-rc.1`.
-We always start with `rc.1` rather than `rc`.
-
-For contract releases, refer to the GitHub release notes for a given release which will list the specific contracts being released. Not all contracts are considered production ready within a release and many are under active development.
-
-Tags of the form `v`, such as `v1.1.4`, indicate releases of all Go code only, and **DO NOT** include smart contracts.
-This naming scheme is required by Golang.
-In the above list, this means these `v` releases contain all `op-*` components and exclude all `contracts-*` components.
-
-`op-geth` embeds upstream geth’s version inside its own version as follows: `vMAJOR.GETH_MAJOR GETH_MINOR GETH_PATCH.PATCH`.
-Basically, geth’s version is our minor version.
-For example if geth is at `v1.12.0`, the corresponding op-geth version would be `v1.101200.0`.
-Note that we pad out to three characters for the geth minor version and two characters for the geth patch version.
-Since we cannot left-pad with zeroes, the geth major version is not padded.
-
-See the [Node Software Releases](https://docs.optimism.io/builders/node-operators/releases) page of the documentation for more information about releases for the latest node components.
-
-The full set of components that have releases are:
-
-- `op-batcher`
-- `op-contracts`
-- `op-challenger`
-- `op-node`
-- `op-proposer`
-
-All other components and packages should be considered development components only and do not have releases.
-
-### Development branch
-
-The primary development branch is [`develop`](https://github.com/ethereum-optimism/optimism/tree/develop/).
-`develop` contains the most up-to-date software that remains backwards compatible with the latest experimental [network deployments](https://docs.optimism.io/chain/networks).
-If you're making a backwards compatible change, please direct your pull request towards `develop`.
-
-**Changes to contracts within `packages/contracts-bedrock/src` are usually NOT considered backwards compatible.**
-Some exceptions to this rule exist for cases in which we absolutely must deploy some new contract after a tag has already been fully deployed.
-If you're changing or adding a contract and you're unsure about which branch to make a PR into, default to using a feature branch.
-Feature branches are typically used when there are conflicts between 2 projects touching the same code, to avoid conflicts from merging both into `develop`.
-
-## License
-
-All other files within this repository are licensed under the [MIT License](https://github.com/ethereum-optimism/optimism/blob/master/LICENSE) unless stated otherwise.
+- [Alt-DA Specification](https://specs.optimism.io/experimental/alt-da.html)
+- [Alt-DA mode explainer](https://docs.optimism.io/chain-operators/guides/configuration/rollup#alt-da-mode)
+- [How to run an Alt-DA mode chain](https://docs.optimism.io/chain-operators/guides/features/alt-da-mode-guide)
-