Merge pull request #967 from onflow/nialexsan/replace-cadence-links

replace cadence 1.0 links

docs/build/basics/fees.md

@@ -328,7 +328,7 @@ access(all) fun add(_ a: Int, _ b: Int): Int {
 
 **Avoid excessive load and save operations**
 
-Avoid costly loading and storage operations and [borrow references](https://cadence-lang.org/docs/1.0/design-patterns#avoid-excessive-load-and-save-storage-operations-prefer-in-place-mutations) where possible, for example:
+Avoid costly loading and storage operations and [borrow references](https://cadence-lang.org/docs/design-patterns#avoid-excessive-load-and-save-storage-operations-prefer-in-place-mutations) where possible, for example:
 
 ```cadence
 transaction {

docs/build/core-contracts/02-fungible-token.md

@@ -6,7 +6,7 @@ sidebar_label: Fungible Token
 
 The `FungibleToken` contract implements the Fungible Token Standard. It is the second contract ever deployed on Flow.
 
-- [Basic Fungible Token Tutorial](https://cadence-lang.org/docs/1.0/tutorial/fungible-tokens)
+- [Basic Fungible Token Tutorial](https://cadence-lang.org/docs/tutorial/fungible-tokens)
 - [Fungible Token Guide](../guides/fungible-token.md)
 - [Fungible Token Standard Repo](https://github.com/onflow/flow-ft)
 

docs/build/core-contracts/08-non-fungible-token.md

@@ -7,7 +7,7 @@ sidebar_label: Non-Fungible Token
 The `NonFungibleToken` contract interface implements the Fungible Token Standard.
 All NFT contracts are encouraged to import and implement this standard.
 
-- [Basic Non-Fungible Token Tutorial](https://cadence-lang.org/docs/1.0/tutorial/non-fungible-tokens-1)
+- [Basic Non-Fungible Token Tutorial](https://cadence-lang.org/docs/tutorial/non-fungible-tokens-1)
 - [Non Fungible Token Guide](../guides/nft.md)
 - [Non Fungible Token Standard Repo](https://github.com/onflow/flow-nft)
 

docs/build/guides/account-linking/index.md

@@ -11,7 +11,7 @@ order to understand how we can achieve that we must first understand how account
 Accounts on flow can be accessed in Cadence through two types, `PublicAccount` and `Account`. As the name implies the
 `PublicAccount` type gives access to all public account information such as address, balance, storage capacity, etc.,
 but doesn't allow changes to the account. The `Account` type (or more specifically, an
-[entitled](https://cadence-lang.org/docs/1.0/language/access-control#entitlements) `&Account`) allows the same access as
+[entitled](https://cadence-lang.org/docs/language/access-control#entitlements) `&Account`) allows the same access as
 `PublicAccount` but also allows changes to the account, including adding/revoking account keys, managing the deployed
 contracts, as well as linking and publishing Capabilities.
 

docs/build/guides/fungible-token.md

@@ -23,8 +23,8 @@ Resources are objects in Cadence that store data,
 but have special restrictions about how they can be stored and transferred,
 making them perfect for representing digital objects with real value.
 
-You can learn more about resources in the Cadence [documentation](https://cadence-lang.org/docs/1.0/language/resources)
-and [tutorials](https://cadence-lang.org/docs/1.0/tutorial/resources).
+You can learn more about resources in the Cadence [documentation](https://cadence-lang.org/docs/language/resources)
+and [tutorials](https://cadence-lang.org/docs/tutorial/resources).
 
 For fungible tokens specifically, tokens are represented by a resource type called a `Vault`:
 
@@ -277,7 +277,7 @@ access(all) contract FooToken: FungibleToken {
 
 As you can see, this function has an `access(FungibleToken.Withdraw)` access modifier.
 This is an example of entitlements in Cadence.
-[Entitlements](https://cadence-lang.org/docs/1.0/language/access-control#entitlements)
+[Entitlements](https://cadence-lang.org/docs/language/access-control#entitlements)
 are a way for developers to restrict access to privileged fields and functions
 in a composite type like a resource when a reference is created for it.
 In this example, the `withdraw()` function is always accessible to code that
@@ -294,15 +294,15 @@ defined by the FungibleToken contract:
 
 Entitlements are important to understand because they are what protects
 privileged functionality in your resource objects from being accessed by third-parties.
-It is recommended to read the [entitlements documentation](https://cadence-lang.org/docs/1.0/language/access-control#entitlements)
+It is recommended to read the [entitlements documentation](https://cadence-lang.org/docs/language/access-control#entitlements)
 to understand how to use the feature properly.
 
-[References](https://cadence-lang.org/docs/1.0/language/references) can be freely up-casted and down-casted in Cadence, so it is important
+[References](https://cadence-lang.org/docs/language/references) can be freely up-casted and down-casted in Cadence, so it is important
 for privileged functionality to be protected by an entitlement so that it can
 only be accessed if it is authorized.
 
 In addition to withdrawing, the vault also needs a way to deposit.
-We'll [typecast](https://cadence-lang.org/docs/1.0/language/operators#casting-operators)
+We'll [typecast](https://cadence-lang.org/docs/language/operators#casting-operators)
 to make sure we are dealing with the correct token, update the vault balance,
 and destroy the vault. Add this code to your resource:
 

docs/build/guides/nft.md

@@ -366,7 +366,7 @@ access(all) resource Collection: NonFungibleToken.Collection {
 
 As you can see, this function has an `access(NonFungibleToken.Withdraw)` access modifier.
 This is an example of entitlements in Cadence.
-[Entitlements](https://cadence-lang.org/docs/1.0/language/access-control#entitlements)
+[Entitlements](https://cadence-lang.org/docs/language/access-control#entitlements)
 are a way for developers to restrict access to privileged fields and functions
 in a composite type like a resource when a reference is created for it.
 In this example, the `withdraw()` function is always accessible to code that
@@ -383,10 +383,10 @@ defined by the `NonFungibleToken` contract:
 
 Entitlements are important to understand because they are what protects
 privileged functionality in your resource objects from being accessed by third-parties.
-It is recommended to read the [entitlements documentation](https://cadence-lang.org/docs/1.0/language/access-control#entitlements)
+It is recommended to read the [entitlements documentation](https://cadence-lang.org/docs/language/access-control#entitlements)
 to understand how to use the feature properly.
 
-[References](https://cadence-lang.org/docs/1.0/language/references) can be freely up-casted and down-casted in Cadence, so it is important
+[References](https://cadence-lang.org/docs/language/references) can be freely up-casted and down-casted in Cadence, so it is important
 for privileged functionality to be protected by an entitlement so that it can
 only be accessed if it is authorized.
 

docs/build/smart-contracts/best-practices/project-development-tips.md

@@ -283,8 +283,8 @@ It also helps the owner to promote the project and themselves.
 
 Resources for Best Practices:
 
-- [cadence/design-pattern](https://cadence-lang.org/docs/1.0/design-patterns)
-- [cadence/anti-patterns](https://cadence-lang.org/docs/1.0/anti-patterns)
+- [cadence/design-pattern](https://cadence-lang.org/docs/design-patterns)
+- [cadence/anti-patterns](https://cadence-lang.org/docs/anti-patterns)
 - [cadence/security-best-practices](./security-best-practices.md)
 
 Composability and extensibility should also be priorities while designing, developing,

docs/build/smart-contracts/best-practices/security-best-practices.md

@@ -6,7 +6,7 @@ sidebar_position: 3
 
 This is an opinionated list of best practices Cadence developers should follow to write more secure Cadence code.
 
-Some practices listed below might overlap with advice in the [Cadence Anti-Patterns](https://cadence-lang.org/docs/1.0/design-patterns) section, which is a recommended read as well.
+Some practices listed below might overlap with advice in the [Cadence Anti-Patterns](https://cadence-lang.org/docs/design-patterns) section, which is a recommended read as well.
 
 ## References
 
@@ -31,7 +31,7 @@ Always [borrow](https://cadence-lang.org/docs/language/capabilities) with the sp
 
 Access to an `&Account` gives access to whatever is specified in the account entitlements
 list when that account reference is created.
-Therefore, [avoid using Account references](https://cadence-lang.org/docs/1.0/anti-patterns#avoid-using-authaccount-as-a-function-parameter) as a function parameter or field unless absolutely necessary and only use the minimal set of entitlements required
+Therefore, [avoid using Account references](https://cadence-lang.org/docs/anti-patterns#avoid-using-authaccount-as-a-function-parameter) as a function parameter or field unless absolutely necessary and only use the minimal set of entitlements required
 for the specified functionality so that other account functionality cannot be accessed.
 
 It is preferable to use capabilities over direct `&Account` references when exposing account data. Using capabilities allows the revocation of access by unlinking and limits the access to a single value with a certain set of functionality.

docs/build/smart-contracts/testing.md

@@ -263,7 +263,7 @@ Tests should also be runnable in automated environments (CI). You can use the [C
 Once you deployed your application to the testnet, you should record how your application handles non-trivial amounts of traffic to ensure there are no issues.
 
 <Callout type="success">
-Get familiar with the [Cadence anti-patterns](https://cadence-lang.org/docs/1.0/anti-patterns) to avoid avoid problematic or unintended behavior.
+Get familiar with the [Cadence anti-patterns](https://cadence-lang.org/docs/anti-patterns) to avoid avoid problematic or unintended behavior.
 </Callout>
 
 

docs/evm/accounts.md

@@ -16,7 +16,7 @@ There are three types of accounts used for EVM on Flow.
 
 1. **Externally Owned Accounts (EOA)**: EOAs are controlled by private individuals using cryptographic keys and can initiate transactions directly. They are the primary account type for users to interact with the blockchain, holding and sending cryptocurrency or calling smart contract functions.
 2. **Contract Accounts**: These accounts hold smart contract code and are governed by this code's logic. Unlike EOAs, Contract Accounts do not initiate transactions on their own but can execute transactions in response to calls they receive from EOAs or other contracts.
-3. **Cadence Owned Accounts (COA)**: This is an account type unique to Flow EVM. These accounts are managed by [Cadence resources](https://cadence-lang.org/docs/1.0/language/resources) and can be used to interact with the Flow EVM from within the Cadence environment.
+3. **Cadence Owned Accounts (COA)**: This is an account type unique to Flow EVM. These accounts are managed by [Cadence resources](https://cadence-lang.org/docs/language/resources) and can be used to interact with the Flow EVM from within the Cadence environment.
 
 EOAs and Contract accounts function the same as on other EVM networks. Users may interact with these accounts using the standard EVM JSON-RPC API ([see endpoints here](./using.mdx)). You can read more about EOAs and Contract accounts on the [Ethereum docs](https://ethereum.org/developers/docs/accounts).
 
@@ -38,7 +38,7 @@ COAs create powerful new opportunities to improve the UX, functionality and util
 
 - **Native Account Abstraction**: COAs are controlled by Cadence resources, which are in turn owned by Flow accounts. [Flow accounts](./accounts.md) have built-in support for multi-signature authentication, key rotation, and account recovery. As a Cadence resource, COAs naturally inherit [these features](../build/advanced-concepts/account-abstraction.md).
 
-- **Fine-Grained Access Control**: As Cadence resources, access to a COA can be governed by more sophisticated policies than those available with basic EVM accounts. By utilizing powerful Cadence access control primitives such as [capabilities and entitlements](https://cadence-lang.org/docs/1.0/language/access-control), developers can restrict who is able to interact with a COA and what actions they are permitted to perform.
+- **Fine-Grained Access Control**: As Cadence resources, access to a COA can be governed by more sophisticated policies than those available with basic EVM accounts. By utilizing powerful Cadence access control primitives such as [capabilities and entitlements](https://cadence-lang.org/docs/language/access-control), developers can restrict who is able to interact with a COA and what actions they are permitted to perform.
 
 ### Differences from Traditional EVM Accounts
 

src/ui/design-system/src/lib/Components/HomepageStartListCadence/index.tsx

@@ -47,7 +47,7 @@ const homepagePillData: Record<string, HomepagePillItemsProps> = {
     subText: 'Chat with devs',
   },
   'network-upgrade': {
-    link: 'https://cadence-lang.org/docs/1.0/cadence-migration-guide/',
+    link: 'https://cadence-lang.org/docs/cadence-migration-guide/',
     icon: 'network-upgrade',
     text: 'Network Upgrade',
     subText: 'View latest',

vercel.json

@@ -1217,12 +1217,12 @@
     },
     {
       "source": "/build/smart-contracts/best-practices/anti-patterns",
-      "destination": "https://cadence-lang.org/docs/1.0/anti-patterns",
+      "destination": "https://cadence-lang.org/docs/anti-patterns",
       "permanent": true
     },
     {
       "source": "/build/smart-contracts/best-practices/design-patterns",
-      "destination": "https://cadence-lang.org/docs/1.0/design-patterns",
+      "destination": "https://cadence-lang.org/docs/design-patterns",
       "permanent": true
     },
     {