diff --git a/docs/build/basics/fees.md b/docs/build/basics/fees.md index 8cd11713e3..9e79cff333 100644 --- a/docs/build/basics/fees.md +++ b/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 { diff --git a/docs/build/core-contracts/02-fungible-token.md b/docs/build/core-contracts/02-fungible-token.md index 6ba79b4c01..906b866f9c 100644 --- a/docs/build/core-contracts/02-fungible-token.md +++ b/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) diff --git a/docs/build/core-contracts/08-non-fungible-token.md b/docs/build/core-contracts/08-non-fungible-token.md index 9e5e974d32..b922506cab 100644 --- a/docs/build/core-contracts/08-non-fungible-token.md +++ b/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) diff --git a/docs/build/guides/account-linking/index.md b/docs/build/guides/account-linking/index.md index c32fa2380d..9e48793fd1 100644 --- a/docs/build/guides/account-linking/index.md +++ b/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. diff --git a/docs/build/guides/fungible-token.md b/docs/build/guides/fungible-token.md index 82da4605af..162819ec0a 100644 --- a/docs/build/guides/fungible-token.md +++ b/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: diff --git a/docs/build/guides/nft.md b/docs/build/guides/nft.md index 83665d70bc..79b7e33d67 100644 --- a/docs/build/guides/nft.md +++ b/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. diff --git a/docs/build/smart-contracts/best-practices/project-development-tips.md b/docs/build/smart-contracts/best-practices/project-development-tips.md index 7ffd03a4aa..9bfe9445fe 100644 --- a/docs/build/smart-contracts/best-practices/project-development-tips.md +++ b/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, diff --git a/docs/build/smart-contracts/best-practices/security-best-practices.md b/docs/build/smart-contracts/best-practices/security-best-practices.md index a6e7d86b21..356e3be084 100644 --- a/docs/build/smart-contracts/best-practices/security-best-practices.md +++ b/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. diff --git a/docs/build/smart-contracts/testing.md b/docs/build/smart-contracts/testing.md index 90b32eb129..7c2b7703db 100644 --- a/docs/build/smart-contracts/testing.md +++ b/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. -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. diff --git a/docs/evm/accounts.md b/docs/evm/accounts.md index e01059682e..228f92e9e4 100644 --- a/docs/evm/accounts.md +++ b/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 diff --git a/src/ui/design-system/src/lib/Components/HomepageStartListCadence/index.tsx b/src/ui/design-system/src/lib/Components/HomepageStartListCadence/index.tsx index 367fbf80f3..9837786578 100644 --- a/src/ui/design-system/src/lib/Components/HomepageStartListCadence/index.tsx +++ b/src/ui/design-system/src/lib/Components/HomepageStartListCadence/index.tsx @@ -47,7 +47,7 @@ const homepagePillData: Record = { 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', diff --git a/vercel.json b/vercel.json index da651fcdac..b5188eed61 100644 --- a/vercel.json +++ b/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 }, {