add docs on alpha- and betanets

pages/stack/public-devnets.mdx

@@ -0,0 +1,56 @@
+---
+title: Public Devnets 
+lang: en-US
+description: An overview of the devnets (alphanets and betanets) which can be used to test upcoming OP Stack releases. 
+---
+
+import { Callout } from 'nextra/components'
+
+OP Labs maintains public devnets, which are designed to streamline testing, iteration, and deployment of new features for the OP Stack.
+There are two different kinds of public devnets: *alphanets* and *betanets*, which serve different purposes and are deployed on different timelines. 
+
+# Alphanets 
+
+**Alphanets** are monthly devnets that include production-bound protocol upgrades that are ready for testing. 
+We rely on alphanets to move faster while improving the reliability of upgrades. 
+If a feature is ready by the monthly deployment date (typically the third Wednesday of the month), the feature will be included in that month's devnet. 
+Otherwise, the feature must wait for the next alphanet. 
+Features _must_ be included on an alphanet before they can be deployed on a betanet.
+
+Alphanets decouple feature development and testing from hardfork scheduling, allowing us to test and iterate on features well in advance of their release on mainnet.
+
+They're designed to stay fresh: Each one is deployed monthly and replaced, so they won't be useable as long-term networks. 
+Each alphanet is launched from genesis, meaning that new features are encoded in genesis rather than undergoing a network upgrade from a preexisting version. 
+The alphanet is then tested, with an emphasis on acceptance testing for new features followed by fault injection testing and performance / load testing. 
+After five weeks, the alphanet is spun down and a new alphanet takes its place, with whatever new features have been developed in that time. 
+
+Alphanets are named after animals and ordered alphabetically.
+
+# Betanets 
+
+**Betanets** are devnets that are deployed on an as-needed basis, typically ahead of an upcoming hardfork. 
+Features are activated using hardfork timestamps, mimicking the production upgrade process.
+
+Betanets are used to solidify the scope of the next hardfork before deploying to the production testnet (e.g., OP Sepolia). 
+A betanet includes the exact set of features that we expect to include in the next network upgrade.
+Features _must_ be included on a betanet before they can be deployed on a testnet.
+
+# Devnet comparison
+
+| Network type        | Alphanet                                   | Betanet                                   |
+| ------------------- | -------------------------------------------| ----------------------------------------- |
+| Purpose             | Early testing of production-bound features | Final validation for the next hardfork    |
+| Deployment          | Monthly                                    | As-needed                                 |
+| Feature activation  | Included and activated at genesis          | Activated through a network upgrade       |
+| Lifecycle           | 5 weeks                                    | Until replaced by the next betanet        |
+
+
+# Current devnets 
+
+**Alpaca** 
+* Launch date: 2025-01-15
+* Anticipated end-of-life: 2025-02-19
+* Scope: Adds updates to the L1 contracts to support upgrades via OP Contracts Manager.
+* RPC endpoint: https://alpaca-0.optimism.io
+* `manifest.yaml`: https://github.com/ethereum-optimism/devnets/blob/main/alphanets/alpaca/manifest.yaml
+