diff --git a/docs/contracts/overview/DigitalAssets.md b/docs/contracts/overview/DigitalAssets.md
deleted file mode 100644
index 4290b8ae5..000000000
--- a/docs/contracts/overview/DigitalAssets.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: 🪙 Digital Asset (Token)
-sidebar_position: 4
----
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-# Digital Assets
-
-The **Digital Asset (Token and NFT 2.0)** contracts are the newest advanced version of the existing token standards. They come with many features that enhance the security and the overall user experience and compatibility with [ERC725Accounts](/standards/accounts/lsp0-erc725account.md) and [Universal Receivers](/standards/accounts/lsp1-universal-receiver.md).
-
-## Comparisons with ERC20 / ERC721
-
-:::danger beware
-
-The LSP7 compatible with ERC20 contracts and LSP8 compatible with ERC721 contracts are being deprecated and will be deleted from [`@lukso/lsp-smart-contracts`](https://github.com/lukso-network/lsp-smart-contracts) repository. However if you want to still use/maintain them, they will remain available in the version [`0.14.0`](https://github.com/lukso-network/lsp-smart-contracts/releases/tag/lsp-smart-contracts-v0.14.0).
-
-:::
-
-The interfaces of LSP7 and LSP8 have some differences compared to ERC20 and ERC721. Their functions are simpler, more straight forward and unified.
-
-**Similar function names**
-
-Both functions in LSP7 and LSP8 have the same name (`transfer`) to transfer assets. This is easier compared to ERC20 and ERC721 that use different naming (`transfer` for ERC20 vs `transferFrom` in ERC721 to transfer tokens as the token owner).
-
-The table below highlights these differences:
-
-
-
- Description |
- ERC20 |
- LSP7 |
-
-
- Transferring tokens as an owner. |
- transfer(address,uint256) |
- transfer(address,address,uint256,bool,bytes) |
-
-
- Transferring tokens as an operator. |
- transferFrom(address,address,uint256) |
-
-
- Approving an operator to spend tokens on behalf of the owner. |
- approve(address,uint256) |
- authorizeOperator(address,uint256) |
-
-
- Description |
- ERC721 |
- LSP8 |
-
-
- Transferring tokens as an owner. |
-
- transferFrom(address,address,uint256)
- safeTransferFrom(address,address,uint256)
- safeTransferFrom(address,address,uint256,bytes)
- |
- transfer(address,address,bytes32,bool,bytes) |
-
-
- Transferring tokens as an operator. |
-
-
- Approving an operator to spend tokens on behalf of the owner. |
- approve(address,uint256) |
- authorizeOperator(address,bytes32) |
-
-
-
-In ERC20 the function `transfer(address,uint256)` is used to transfer ERC20 tokens from the caller, this can only be used by the holder of the ERC20 tokens. There is also `transferFrom(address,address,uint256)` which can also be used by the ERC20 tokens operator.
-
-In comparison ERC721 has:
-
-- `safeTransferFrom(address,address,uint256,bytes)`
-- `safeTransferFrom(address,address,uint256)`
-- `transferFrom(address,address,uint256)`
-
-All of the above functions can be used by both the owner of the token id or by the operator of the token id in order to transfer the ERC721 token. To be mentioned, both functions `safeTransferFrom(...)` have a hook that calls the recipient contract.
-
-Looking at LSP7 & LSP8 we have unified `transfer(...)` & `transferBatch(...)` functions in both contracts. Those functions contain a hook which is executed conditionally and can be used in any of the above cases.
-
-## LSP4 Digital Asset Metadata
-
-The **LSP4DigitalAssetMetadata** is a contract that sets the **Token-Metadata** (name and symbol) for the **LSP7DigitalAsset** and **LSP8IdentifiableDigitalAsset** token contracts.
-
-Since it uses **[ERC725Y General Data Key/Value Store](https://eips.ethereum.org/EIPS/eip-725)** to set the metadata, any information can be added (_e.g: **list of creators, JSON files**, etc_).
-
-## LSP7 Digital Asset
-
-The **LSP7DigitalAsset** contract represents digital assets for fungible tokens where minting and transferring are specified with an amount of tokens. Their functions were inspired from **[ERC20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)** and **[ERC1155](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC1155/ERC1155.sol)** with more upgraded features.
-
-An LSP7 can serves as:
-
-- a **Divisible Token Contract** when `isNonDivisible` bool is set to `false` in the [`constructor(...)`](#constructor)
-- otherwise serves as a **Non-Divisible Token Contract**.
-
-This can be useful to set `isNonDivisible` to `true`, rather than deploying a LSP8 contract to achieve the same goal.
-
-### Create a Fungible Token
-
-```solidity
-// MyToken.sol
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-import "@lukso/lsp-smart-contracts/contracts/LSP7DigitalAsset/LSP7DigitalAsset.sol";
-
-contract MyToken is LSP7DigitalAsset {
- // 4th argument (false) marks that this contract serves as a Fungible Token and not as a NFT.
- constructor() LSP7DigitalAsset("MyToken","MTKN",msg.sender,false) {
- // ..
- }
-
- function mint() public {
- _mint(...);
- }
-}
-```
-
-## Extensions
-
-The smart contracts packages for `@lukso/lsp7-contracts` and `@lukso/lsp8-contracts` include token extensions (similarly to OpenZeppelin contracts) that enables to include functionalities for building your token through inheritance.
-
-**LSP7 Tokens extensions:**
-
-- [`LSP7Burnable.sol`](../contracts/LSP7DigitalAsset/extensions/LSP7Burnable.md): exposes a public `burn(...)` function that allows any token holder or operator to burn any amount of tokens.
-- [`LSP7CappedSupply.sol`](../contracts/LSP7DigitalAsset/extensions/LSP7CappedSupply.md): enable to specify a maximum supply on deployment / initialization, which cap the maximum amount of tokens that can be minted.
-
-**LSP8 NFTs extensions:**
-
-- [`LSP8Burnable.sol](../contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8Burnable.md)`: exposes a public `burn(...)` function that allows any NFT holder or operator to burn a specific NFT tokenId.
-- [`LSP8CappedSupply.sol](../contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8CappedSupply.md)`: enable to specify a maximum supply on deployment / initialization, which cap the maximum amount of NFT that can be minted in the collection.
-- [`LSP8Enumerable.sol](../contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8Enumerable.md)`: functionality to enumerate the list of NFTs in a collection.
-
-If your token contract uses the proxy pattern with initialize functions, use the `InitAbstract` version of these extension contracts (\_e.g: `LSP7Burnable` -> `LSP7BurnableInitAbstract`).
-
-## Custom logic for transfers
-
-The LSP7 and LSP8 implementations provide the `_beforeTokenTransfer` and `_afterTokenTransfer` function that offer the ability to specify custom logic that can run before or after the token transfer has happen (= before or after the balances in the contract state have been updated).
-
-## Note on LSP7 and LSP8 implementations
-
-`LSP7DigitalAsset.sol` and `LSP8IdentifiableDigitalAsset.sol` are `abstract` contracts that are not deployable as they are, because they do not contain any public functions by default to manage token supply (_e.g: no public `mint(...)` or `burn(...)` functions_). You can either:
-
-- use `LSP7Mintable` or `LSP8Mintable`, a preset contract that contains a public `mint(...)` function callable only by the contract's owner.
-- or extend the `LSP7DigitalAsset` / `LSP8IdentifiableDigitalAsset` contract and create your own supply mechanism by defining public methods that use the internal `_mint(...)` and `_burn(...)` functions.
diff --git a/docs/contracts/overview/NFT/_category_.yml b/docs/contracts/overview/NFT/_category_.yml
new file mode 100644
index 000000000..57092f5c8
--- /dev/null
+++ b/docs/contracts/overview/NFT/_category_.yml
@@ -0,0 +1,4 @@
+label: 🖼️ Identifiable Digital Asset (NFT)
+position: 5
+collapsible: true
+collapsed: true
diff --git a/docs/contracts/overview/NFT/create-nft-collection.md b/docs/contracts/overview/NFT/create-nft-collection.md
new file mode 100644
index 000000000..bb6285352
--- /dev/null
+++ b/docs/contracts/overview/NFT/create-nft-collection.md
@@ -0,0 +1,52 @@
+---
+title: Create a Non Fungible Token
+sidebar_position: 1
+---
+
+# Create a Non Fungible Token
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.4;
+
+// modules
+import {
+ LSP8IdentifiableDigitalAsset
+} from "@lukso/lsp8-contracts/contracts/LSP8IdentifiableDigitalAsset.sol";
+
+// constants
+import {
+ _LSP8_TOKENID_FORMAT_NUMBER
+} from "@lukso/lsp8-contracts/contracts/LSP8Constants.sol";
+import {
+ _LSP4_TOKEN_TYPE_COLLECTION
+} from "@lukso/lsp4-contracts/contracts/LSP4Constants.sol";
+
+contract BasicNFTCollection is LSP8IdentifiableDigitalAsset {
+ constructor(
+ string memory nftCollectionName,
+ string memory nftCollectionSymbol,
+ address contractOwner
+ )
+ LSP8IdentifiableDigitalAsset(
+ nftCollectionName,
+ nftCollectionSymbol,
+ contractOwner,
+ _LSP4_TOKEN_TYPE_COLLECTION,
+ _LSP8_TOKENID_FORMAT_NUMBER
+ )
+ {
+ // contract logic goes here...
+ }
+}
+```
+
+## LSP8 NFT extensions
+
+The `@lukso/lsp8-contracts` package includes token extensions (similarly to OpenZeppelin contracts) that can be added through inheritance. This enables to include specific functionalities for building your token.
+
+| Extension contract | Description |
+| :---------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- |
+| [`LSP8Burnable.sol`](../../contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8Burnable.md) | exposes a public `burn(...)` function that allows any NFT holder or operator to burn a specific NFT tokenId. |
+| [`LSP8CappedSupply.sol`](../../contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8CappedSupply.md) | enable to specify a maximum supply on deployment / initialization, which caps the maximum amount of NFT that can be minted in the collection. |
+| [`LSP8Enumerable.sol`](../../contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8Enumerable.md) | functionality to enumerate the list of NFTs in a collection. |
diff --git a/docs/contracts/overview/NFT/customise-transfer-behaviour.md b/docs/contracts/overview/NFT/customise-transfer-behaviour.md
new file mode 100644
index 000000000..5ba93b91e
--- /dev/null
+++ b/docs/contracts/overview/NFT/customise-transfer-behaviour.md
@@ -0,0 +1,8 @@
+---
+title: Customize transfer behaviour
+sidebar_position: 2
+---
+
+# Customize transfer behaviour
+
+The `LSP8IdenfitiableDigitalAsset` contract implementation includes the `_beforeTokenTransfer` and `_afterTokenTransfer` functions that offer the ability to specify custom logic that can run before or after the token transfer has happen (= before or after the balances in the contract state have been updated).
diff --git a/docs/contracts/overview/NFT/index.md b/docs/contracts/overview/NFT/index.md
new file mode 100644
index 000000000..1c4628172
--- /dev/null
+++ b/docs/contracts/overview/NFT/index.md
@@ -0,0 +1,91 @@
+---
+title: 🖼️ Identifiable Digital Asset (NFT)
+sidebar_position: 5
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# LSP8 Identifiable Digital Asset
+
+:::danger Deprecation of `LSP8CompatibleERC721`
+
+The `LSP8CompatibleERC721` contracts have been deprecated and deleted from the [`@lukso/lsp-smart-contracts`](https://github.com/lukso-network/lsp-smart-contracts) package since version `0.15.0`, because of their unsafe nature and [security considerations (See PR #845 for more details)](https://github.com/lukso-network/lsp-smart-contracts/pull/845#issuecomment-1888671461).
+
+They are not recommended to be used. However, if you want to still use them, they remain available in the version [`0.14.0`](https://github.com/lukso-network/lsp-smart-contracts/releases/tag/lsp-smart-contracts-v0.14.0).
+
+:::
+
+The **LSP8 Identifiable Digital Asset** contract is the newest advanced version of the existing ERC NFT standards, such as ERC721. LSP8 identifiable digital assets represent **N**on **F**ungible **T**okens (NFTs) that can be uniquely traded. Each NFT is identified with a tokenId, based on **[ERC721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)** and can also have its own metadata set using the **[`setDataForTokenId(...)`](../../contracts/LSP8IdentifiableDigitalAsset/LSP8IdentifiableDigitalAsset.md#setdatafortokenid)** function.
+
+A **bytes32** value is used for tokenId to allow many uses of token identification, including numbers, contract addresses, and hashed values (i.e., serial numbers).
+
+## Installation & Usage
+
+The LSP8 smart contracts and their ABIs are available are available in their own individual package. To use them, install `@lukso/lsp8-contracts` as a dependency in your project.
+
+
+
+ Description |
+ ERC721 |
+ LSP8 |
+
+
+ Transferring tokens as an owner. |
+
+ transferFrom(address,address,uint256)
+ safeTransferFrom(address,address,uint256)
+ safeTransferFrom(address,address,uint256,bytes)
+ |
+ transfer(address,address,bytes32,bool,bytes) |
+
+
+ Transferring tokens as an operator. |
+
+
+ Approving an operator to spend tokens on behalf of the owner. |
+ approve(address,uint256) |
+ authorizeOperator(address,bytes32) |
+
+
+
+In comparison ERC721 has:
+
+- `safeTransferFrom(address,address,uint256,bytes)`
+- `safeTransferFrom(address,address,uint256)`
+- `transferFrom(address,address,uint256)`
+
+All of the above functions can be used by both the owner of the token id or by the operator of the token id in order to transfer the ERC721 token. To be mentioned, both functions `safeTransferFrom(...)` have a hook that calls the recipient contract.
+
+Looking at LSP7 & LSP8 we have unified `transfer(...)` & `transferBatch(...)` functions in both contracts. Those functions contain a hook which is executed conditionally and can be used in any of the above cases.
diff --git a/docs/contracts/overview/IdentifiableDigitalAssets.md b/docs/contracts/overview/NFT/set-nft-metadata.md
similarity index 77%
rename from docs/contracts/overview/IdentifiableDigitalAssets.md
rename to docs/contracts/overview/NFT/set-nft-metadata.md
index de6d4a2d6..fee3c11f6 100644
--- a/docs/contracts/overview/IdentifiableDigitalAssets.md
+++ b/docs/contracts/overview/NFT/set-nft-metadata.md
@@ -1,27 +1,20 @@
---
-title: 🖼️ Identifiable Digital Asset (NFT)
-sidebar_position: 5
+title: Set NFT Metadata
+sidebar_position: 3
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-## LSP8 Identifiable Digital Asset
+# Set NFT Metadata
-The **LSP8IdentifiableDigitalAsset** contract represents identifiable digital assets (NFTs) that can be uniquely traded and given metadata using the **[ERC725Y Standard](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md#erc725y)**.
-Each NFT is identified with a tokenId, based on **[ERC721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)**.
+The function [`setDataBatchForTokenIds(...)`](../../contracts/LSP8IdentifiableDigitalAsset/LSP8IdentifiableDigitalAsset.md#setdatabatchfortokenids) can be used to set multiple [data key-value](/standards/erc725.md#erc725y-generic-data-keyvalue-store) pairs at once for one or multiple tokenIds.
-A **bytes32** value is used for tokenId to allow many uses of token identification, including numbers, contract addresses, and hashed values (i.e., serial numbers).
+## Examples
-### Setting metadata for one or multiple tokenIds
+### Set multiple metadata at once on the same tokenId
-The function [`setDataBatchForTokenIds(...)`](../../contracts/contracts/LSP8IdentifiableDigitalAsset/LSP8IdentifiableDigitalAsset.md#setdatabatchfortokenids) can be used to set multiple data key-value pairs at once for one or multiple tokenIds.
-
-This function is flexible enough to enable to set one or multiple [data key-value](/standards/erc725).md#erc725y-generic-data-keyvalue-store) pairs for:
-
-#### case 1: a single tokenId
-
-To set for instance 3 x data key-value pairs for the same `tokenId`, the parameters of `setDataBatchForTokenIds(bytes32[],bytes32[],bytes[])` will be as follow:
+To set for instance 3 x data key-value pairs for the same `tokenId`, the parameters of `setDataBatchForTokenIds(bytes32[],bytes32[],bytes[])` can be used as follow: