decouple stable version (#278)

.gitignore

@@ -35,10 +35,10 @@ docs/.obsidian
 
 # Remove after cadence is updated to a stable version
 # https://github.com/onflow/docs/issues/105
-versioned_docs/version-stable/building-on-flow
-versioned_docs/version-stable/community-resources
-versioned_docs/version-stable/concepts
-versioned_docs/version-stable/references
-versioned_docs/version-stable/tools
-versioned_docs/version-stable/guides
+# versioned_docs/version-stable/building-on-flow
+# versioned_docs/version-stable/community-resources
+# versioned_docs/version-stable/concepts
+# versioned_docs/version-stable/references
+# versioned_docs/version-stable/tools
+# versioned_docs/version-stable/guides
 # versioned_docs/version-stable/tutorials

scripts/import.sh

@@ -102,4 +102,4 @@ copyRepoFilesToDest() {
 }
 
 cloneDocReposToDest
-copyVersionedDocs
+# copyVersionedDocs

versioned_docs/version-stable/building-on-flow/app-architecture/index.md

@@ -0,0 +1,78 @@
+---
+sidebar_position: 3
+title: App Architecture
+description: Describes building self-custody and app custody applications on Flow Blockchain.
+sidebar_custom_props:
+  icon: 🏗️
+---
+
+# App Architecture on Flow Blockchain
+
+The Flow blockchain, with its focus on scalability and user-centric design, offers a unique environment for app development. Designed from the ground up, Flow prioritizes user experience, aiming to bridge the gap to mainstream adoption without compromising on decentralization or security.
+
+While the Flow blockchain offers various architectural patterns, the recommended approaches for developers are **Self-Custody** and **App Custody**. These choices align with Flow's ethos of user-centric design and flexibility.
+
+### **Self-Custody Architecture**
+
+In a self-custody architecture, users retain direct control over their private keys and assets. This model emphasizes user sovereignty and decentralization, placing the responsibility of asset management squarely on the user's shoulders. While it offers the highest degree of control, it also demands a certain level of technical knowledge and awareness from the user, which can sometimes lead to a more complex user experience.
+
+![self-custody.png](self-custody.png)
+
+**Architectural Elements**:
+
+- **Wallet**: A wallet where users store their private keys and sign transactions.
+- **Frontend**: Interfaces directly with the user and their wallet for signing transactions.
+- **Method of Talking to Chain**: Through FCL directly.
+
+**Benefits**:
+
+- **Control**: Users maintain full ownership of their assets and transactions.
+- **Security**: Direct management of private keys reduces potential points of failure.
+
+**Considerations**:
+
+- **User Experience**: The direct control model can lead to a more complex user experience, especially for those unfamiliar with blockchain. Typically, all transactions must be approved by the user, which can be cumbersome.
+- **Key Management**: Users are solely responsible for managing, backing up, and ensuring the safe generation and storage of their keys.
+
+**Ideal Use Cases**:
+
+- **Decentralized Finance (DeFi)**: Users interacting with financial protocols while maintaining full control.
+- **Web3 Native Users**: Those familiar with blockchain technology and key management.
+
+### **App Custody Architecture**
+
+App custody on Flow offers a unique approach to key management and user experience. Unlike traditional app custody solutions on other blockchains, Flow's App Custody architecture introduces features like **account linking** and **walletless onboarding**. These features ensure that while users enjoy a seamless experience, they still have the option to link their accounts and move their assets freely around the Flow ecosystem, providing a balanced approach to key management.
+
+![app-custody.png](app-custody.png)
+
+**Architectural Elements**:
+
+- **Wallet**: Both user custody and app custody wallets coexist.
+- **Frontend**: Interfaces for both wallet types and features for account linking and walletless onboarding.
+- **Backend**: Manages app-custody user keys and assets.  Also supports direct blockchain interactions.
+- **Method of Interacting with the Chain**: Both direct FCL calls and backend-managed interactions.
+- **Payment Rails**: Flexible methods, accommodating both direct and managed transactions.
+
+**Benefits**:
+
+- **Walletless Onboarding**: Users can start interacting with the app using traditional, familiar web2 mechanics without the initial need for a blockchain wallet.
+- **Streamlined Experience**: Transactions can be processed without constant user approval, offering a smoother user journey.
+- **Open Ecosystem with Account Linking**: Users can link their accounts, ensuring they can move their assets freely around the Flow ecosystem without being locked into a single application.
+- **Flexibility**: Cater to both tech-savvy users and newcomers without compromising on security.
+- **Platform Versatility**: The abstraction of the user wallet allows for integration with various platforms, including Unity games, consoles, and mobile applications.
+
+**Considerations**:
+
+- **Complexity**: Implementing app custody can be more intricate.
+- **Trust**: Users need to trust the dApp with certain aspects of their data and assets.
+- **Legal Implications**: Operating with app custody may come with legal considerations, depending on jurisdiction and the nature of the dApp. It's essential to consult with legal professionals to ensure compliance.
+
+**Ideal Use Cases**:
+
+- **Gaming**: Seamless gaming without constant transaction approvals.
+- **Social Media Platforms**: Earning tokens for content without initial blockchain familiarity.
+- **Loyalty Programs**: Earning rewards without deep blockchain setup.
+
+## Wrapping Up
+
+Selecting the right architecture is crucial when developing an app on the Flow blockchain. Your choice will influence not only the technical aspects but also the user experience and overall trust in your application. While Flow offers the tools and flexibility to cater to various needs, it's up to developers to harness these capabilities effectively. Whether you opt for a self-custody or app custody approach, ensure that your decision aligns with the core objectives of your app and the expectations of your users. Making informed architectural decisions will lay a strong foundation for your app's success.

versioned_docs/version-stable/building-on-flow/building-vs-other-chains.md

@@ -0,0 +1,193 @@
+---
+sidebar_position: 3
+title: Differences vs. Other Blockchains
+sidebar_custom_props:
+  icon: ↔️
+---
+
+This document summarizes the differences you might encounter between building on Flow vs. other blockchains, especially Ethereum. This will be most useful to developers who are already familiar with building on a blockchain system. Check out [Introduction to Flow](../concepts/start-here.md) for a more beginner-friendly overview of the Flow blockchain.
+
+Summary of key differences covered:
+
+- The Flow account model
+- Smart contracts
+    - The Cadence language
+    - Transactions and Scripts
+    - Events
+- Nodes
+- SDKs and Tools
+
+## The Flow Account Model
+
+Key pairs establish ownership on blockchains. In other blockchains (e.g. Bitcoin), the user’s address is also calculated based on their public key, making a unique one-to-one relationship between accounts (addresses) and public keys. This also means there is no concrete “account creation” process other than generating a valid key pair. With the advent of smart contracts, Ethereum introduced a new account type for deploying contracts that can use storage space (i.e., to store contract bytecode). You can learn more about the distinction between EOA and Contract accounts on Ethereum [here](https://ethereum.org/en/developers/docs/accounts/).
+
+Flow combines the concepts of EOAs and Contract Accounts into a single account model and decouples accounts and public keys. Flow accounts are associated with one or more public keys of varying weights that specify interested parties that need to produce valid cryptographic signatures for each transaction authorized by that account.
+
+![Screenshot 2023-08-16 at 16.43.07.png](../concepts/_accounts_images/Screenshot_2023-08-16_at_16.43.07.png)
+
+This natively enables interesting use cases, like key revocation, rotation, and multi-signature transactions. All Flow accounts can use network storage (e.g., for deploying contracts and storing resources like NFTs) based on the number of FLOW tokens they hold.
+
+<Callout type="info">
+
+You must run an explicit account creation transaction on Flow to create a new account. [Flow CLI](../tools/toolchains/flow-cli/accounts/create-accounts.md) can create an account on any network with a given public key.
+
+</Callout>
+
+Check out the [Accounts](../concepts/accounts.md) concept document to learn more about Flow accounts.
+
+## Smart Contracts
+
+On Flow, smart contracts are written in Cadence. Cadence syntax is user-friendly and inspired by modern languages like Swift. Notable features of Cadence that make it unique and the key power of the Flow blockchain are:
+
+- **Resource-oriented**: Cadence introduces a new type called Resources. Resources enable onchain representation of digital assets natively and securely. Resources can only exist in one location at a time and are strictly controlled by the execution environment to avoid common mishandling mistakes. Each resource has a unique `uuid` associated with it on the blockchain. Examples of usage are fungible tokens, NFTs, or any custom data structure representing a real-world asset. Check out [Resources](../cadence/language/resources.mdx) to learn more.
+- **Capability-based**: Cadence offers a [Capability-based Security](https://en.wikipedia.org/wiki/Capability-based_security) model. This also enables the use of Resources as structures to build access control. Capabilities can provide fine-grained access to the underlying objects for better security. For example, when users list an NFT on a Flow marketplace, they create a new Capability to the stored NFT in their account so the buyer can withdraw the asset when they provide the tokens. Check out [Capability-based Access Control](https://developers.flow.com/cadence/language/capability-based-access-control.md) to learn more about Capabilities on Cadence.
+
+<Callout type="info">
+
+Cadence is not compiled. All contracts are open source on Flow.
+
+</Callout>
+
+Check out the [Cadence website](https://cadencelang.dev/) to learn more about Cadence.
+
+If you’re already familiar with smart contracts, here are some resources that can help you get started with Cadence:
+
+- [The Cadence tutorial](../cadence/tutorial/01-first-steps.mdx)
+- [Guide for Solidity Developers](../cadence/solidity-to-cadence.mdx)
+- ERC-20 equivalent on Flow is the Flow Fungible Token Standard
+    - [Repository](https://github.com/onflow/flow-ft)
+    - [Tutorial](../cadence/tutorial/06-fungible-tokens.mdx)
+- ERC-721 equivalent on Flow is the Flow Non-Fungible Token Standard
+    - [Repository](https://github.com/onflow/flow-nft)
+    - [Tutorial](../cadence/tutorial/05-non-fungible-tokens-1.mdx)
+- Asset marketplaces with Cadence
+    - [Tutorial](../cadence/tutorial/07-marketplace-setup.mdx)
+    - [NFT Storefront](https://github.com/onflow/nft-storefront/) is an example marketplace standard
+
+### Transactions and Scripts
+
+You can interact with the state on most other blockchains by cryptographically authorizing smart contract function calls. On Flow, transactions are more complex and are pieces of Cadence code. This means that any number of contracts and function calls can be composed together atomically to mutate the blockchain state.
+
+Here is a sample transaction that mints an NFT from `ExampleNFT` contract on Testnet:
+
+```cadence
+import NonFungibleToken from 0x631e88ae7f1d7c20
+import ExampleNFT from 0x2bd9d8989a3352a1
+
+/// Mints a new ExampleNFT into recipient's account
+
+transaction(recipient: Address) {
+
+    /// Reference to the receiver's collection
+    let recipientCollectionRef: &{NonFungibleToken.CollectionPublic}
+
+    /// Previous NFT ID before the transaction executes
+    let mintingIDBefore: UInt64
+
+    prepare(signer: AuthAccount) {
+
+        self.mintingIDBefore = ExampleNFT.totalSupply
+
+        // Borrow the recipient's public NFT collection reference
+        self.recipientCollectionRef = getAccount(recipient)
+            .getCapability(ExampleNFT.CollectionPublicPath)
+            .borrow<&{NonFungibleToken.CollectionPublic}>()
+            ?? panic("Could not get receiver reference to the NFT Collection")
+
+    }
+
+    execute {
+
+        let currentIDString = self.mintingIDBefore.toString()
+
+        // Mint the NFT and deposit it to the recipient's collection
+        ExampleNFT.mintNFT(
+            recipient: self.recipientCollectionRef,
+            name: "Example NFT #".concat(currentIDString),
+            description: "Example description for #".concat(currentIDString),
+            thumbnail: "https://robohash.org/".concat(currentIDString),
+            royalties: []
+        )
+    }
+
+    post {
+        self.recipientCollectionRef.getIDs().contains(self.mintingIDBefore): "The next NFT ID should have been minted and delivered"
+        ExampleNFT.totalSupply == self.mintingIDBefore + 1: "The total supply should have been increased by 1"
+    }
+}
+```
+
+Authorizing transactions is also more complex on Flow involving multiple roles:
+
+- Accounts can have multiple keys with varying weights
+- Multiple accounts can sign a single transaction (`prepare` takes any number of arguments)
+- Transaction computation fees can be paid by a different account, called the `Payer` account.
+- The transaction [nonce](https://ethereum.org/en/developers/docs/accounts/#an-account-examined) is provided by the `Proposer` account. This enables rate control and order to be dictated by a different party if needed.
+- All of the above roles can be the same account.
+
+The same powerful concept also exists for querying the blockchain state using Scripts. Here is a sample script that fetches the `ExampleNFT` IDs owned by a given account on Testnet:
+
+```cadence
+/// Script to get NFT IDs in an account's collection
+
+import NonFungibleToken from 0x631e88ae7f1d7c20
+import ExampleNFT from 0x2bd9d8989a3352a1
+
+pub fun main(address: Address, collectionPublicPath: PublicPath): [UInt64] {
+
+    let account = getAccount(address)
+
+    let collectionRef = account
+        .getCapability(collectionPublicPath)
+        .borrow<&{NonFungibleToken.CollectionPublic}>()
+        ?? panic("Could not borrow capability from public collection at specified path")
+
+    return collectionRef.getIDs()
+
+}
+```
+
+Check out [Transactions](../concepts/transactions.md) and [Scripts](../concepts/scripts.md) to learn more about the concepts. You can also read the Cadence language reference on [Transactions](../cadence/language/transactions.md) to dive deeper.
+
+## Flow Nodes
+
+Developers need a blockchain node to send transactions and fetch state. Flow is based on a multi-node architecture that separates roles like consensus and computation. You can learn more about the Flow architecture [here](https://flow.com/primer#primer-how-flow-works).
+
+Access Nodes are the node type that are most useful for developers, as they provide access to the Flow network via an API. Flow provides public access nodes for multiple networks. They provide two flavours of APIs:
+
+- [HTTP API](https://developers.flow.com/http-api)
+- gRPC
+    - Mainnet: `access.mainnet.nodes.onflow.org:9000`
+    - Testnet: `access.devnet.nodes.onflow.org:9000`
+    - [Specification](./run-and-secure/nodes/access-api.mdx)
+
+### Running Your Own Node
+
+If you’re getting started you don’t need to run your own node and you can use the above public nodes. The public access nodes are rate-limited, so as your product matures you might want to run your own node. There are multiple options available:
+
+- Start with a [Light (Observer) Node](./run-and-secure/nodes/node-operation/observer-node.mdx).
+- You can also use a third-party provider like [Quicknode](https://www.quicknode.com/docs/flow).
+
+Check out [Running a Node](../guides/runningNode.mdx) for more information.
+
+## SDKs and Tools
+
+If you’re already familiar with blockchain development, here's a comparison between popular software packages and Flow's tooling:
+
+- [hardhat](https://hardhat.org/) / [Truffle](https://trufflesuite.com/) / [Foundry](https://github.com/foundry-rs/foundry)
+    - [Flow CLI](https://github.com/onflow/flow-cli/) provides local development tools and the [Flow Emulator](https://github.com/onflow/flow-emulator)
+- [OpenZeppelin](https://www.openzeppelin.com/)
+    - No equivalent, you can pick contracts from any core Flow contract repository
+- [go-ethereum](https://geth.ethereum.org/)
+    - [Flow Go SDK](https://github.com/onflow/flow-go-sdk/)
+    - [FCL](https://github.com/onflow/fcl-js/) also provides Backend API for Flow in JS
+- [web3.js](https://github.com/web3/web3.js)
+    - [FCL](https://github.com/onflow/fcl-js/)
+    - [flow-cadut](https://github.com/onflow/flow-cadut) provides more utilities for using Flow on Web
+- [Remix](https://remix.ethereum.org/)
+    - [Flow Playground](https://play.flow.com/) provides basic experimentation on the web
+    - [Cadence VSCode Extension](https://marketplace.visualstudio.com/items?itemName=onflow.cadence) is strongly suggested to install for local development
+- [Testing Smart Contracts](https://ethereum.org/en/developers/docs/smart-contracts/testing/)
+    - [Cadence testing framework](../cadence/testing-framework.mdx) enables native tests in Cadence.
+    - [overflow](https://github.com/bjartek/overflow) for testing in Go.
+    - [js-testing](https://github.com/onflow/flow-js-testing) for testing in JS.

versioned_docs/version-stable/building-on-flow/core-contracts/02-fungible-token.md

@@ -0,0 +1,15 @@
+---
+title: Fungible Token Contract
+sidebar_label: Fungible Token
+---
+
+The `FungibleToken` contract implements the Fungible Token Standard. It is the second contract ever deployed on Flow.
+
+Source: [FungibleToken.cdc](https://github.com/onflow/flow-ft/blob/master/contracts/FungibleToken.cdc)
+
+| Network         | Contract Address     |
+| --------------- | -------------------- |
+| Emulator/Canary | `0xee82856bf20e2aa6` |
+| Testnet         | `0x9a0766d93b6608b7` |
+| Mainnet         | `0xf233dcee88fe0abe` |
+