bloock · edutomesco · Mar 15, 2024 · Mar 15, 2024 · Mar 15, 2024
diff --git a/docs/guides/products/integrity/concepts/_category_.json b/docs/guides/products/integrity/concepts/_category_.json
@@ -0,0 +1,5 @@
+{
+  "position": 2,
+  "label": "Concepts",
+  "collapsible": true
+}
diff --git a/docs/guides/products/integrity/concepts/anchor-entity.mdx b/docs/guides/products/integrity/concepts/anchor-entity.mdx
@@ -0,0 +1,27 @@
+---
+title: 'Anchor entity'
+sidebar_position: 4
+---
+
+# The anchor entity
+
+As described in the [Protocol Overview](./protocol.mdx#protocol-overview), we use a set of sparse Merkle trees that forms our Rollup. Once you send some data, it gets enqueued until we trigger the anchor mechanism.
+
+This process consists in getting all the pending data and adding them to the state tree. This will produce a state transition and the resulting root will be transacted into several blockchain networks following the time intervals described in the [Networks supported](./networks-supported.mdx#networks-supported) section.
+
+:::tip
+As a more formal definition: An anchor is a snapshot of the state tree which is registered to the blockchain protocol. It is formed by the resulting state of the state transition.
+:::
+
+### Anchor identifier
+
+We identify anchors with sequential numbers starting from 1. When you send a new data for certification, you will receive the anchor identifier in which your data will be processed, usually this is the next available one.
+
+### Relation of anchors with blockchain networks
+
+It's important to note that not all the anchors processed are transacted into all the blockchain networks supported by BLOOCK. This means that if you directly query some root of a random anchor into a network, it's possible (and common) that the result is not found.
+This is because we have different transaction intervals for the different networks supported. However, we do guarantee that every anchor gets transacted to at least one network.
+The integrity proof retrieval process manages this so you don't get an integrity proof that results in a root not transacted to the selected network.
+For a better understanding of this topic, here's a diagram of how anchors and transactions work together:
+
+![5 - Integrity](/static/docs/guides/integrity/5-integrity.png)
diff --git a/docs/guides/products/integrity/concepts/integrity-proof-entity.mdx b/docs/guides/products/integrity/concepts/integrity-proof-entity.mdx
@@ -0,0 +1,28 @@
+---
+title: 'Integrity proof entity'
+sidebar_position: 5
+---
+
+# The integrity proof entity {#integrity-proof-entity}
+
+Once a data submitted to BLOOCK for certification gets included in an anchor, you are able to retrieve an integrity proof for it.
+This proof is computed as an optimized Merkle proof by BLOOCK representing the minimal necessary data to mathematically prove that a record was included at a certain point in time to the blockchain. The computed proof has the following properties:
+Timeless, meaning that, once retrieved, those can be verified at any time in the future.
+
+- Proofs can be retrieved for multiple records which enables to verify the existence of a set of records at once.
+- Proofs are auto verifiable by the user without the intervention of BLOOCK.
+
+:::tip
+It's important to note that BLOOCK is not able to emit fraudulent proofs because of the cryptographic properties of the Merkle trees.
+:::
+
+When you retrieve an integrity proof for one or more data to be able to further verify them, you will receive a set of data consisting of:
+
+| Field  | Description                                                                                            |
+| ------ | ------------------------------------------------------------------------------------------------------ |
+| Leaves | An array of hashes that contains exactly the input data to get the integrity proof from.               |
+| Nodes  | An array of hashes that will be combined with the leaves to run the Merkle proof verification process. |
+| Bitmap | Hexadecimal value used to combine the leaves and nodes in order to correctly compute the proof.        |
+| Depth  | Additional information needed to run the verification process.                                         |
+| Root   | The anchor root that the integrity proof should resolve to when verified.                              |
+| Anchor | Contains information related to the anchor from which the integrity proof was computed from.           |
diff --git a/...products/integrity/networks-supported.mdx → ...integrity/concepts/networks-supported.mdx b/...products/integrity/networks-supported.mdx → ...integrity/concepts/networks-supported.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Networks supported'
-sidebar_position: 3
+sidebar_position: 2
 ---
 
-# Networks supported
+# Networks supported {#networks-supported}
 
 BLOOCK's protocol allows for interoperability between different blockchain networks, meaning that anchors processed by our system gets transacted in multiple chains so you are able to verify your data in any of them.
 
@@ -16,7 +16,7 @@ This allows for different benefits for our customers such as:
 
 We transact to each network in different intervals. This is because of two reasons: the chain's block interval and the transaction cost.
 
-## Live environment
+## Networks
 
 Here is a list of blockchain we integrate with and the the approximate transaction intervals:
 
@@ -46,13 +46,3 @@ Here is a list of blockchain we integrate with and the the approximate transacti
     </tr>
   </tbody>
 </table>
-
-## Test environment
-
-Our test environment is designed for development-only purposes, providing low transaction intervals to facilitate the development and integration with our SDKs.
-
-To do so, anchors processed in that environment are only transacted into a private EVM-compatible blockchain managed by BLOOCK called BloockChain:
-
-| Network     | Contract address                         | Interval   |
-| ----------- | ---------------------------------------- | ---------- |
-| BloockChain | d2d1BBcbee7741f8C846826F55b7c17fc5cf969a | \~1 minute |
diff --git a/docs/guides/products/integrity/protocol.mdx → .../products/integrity/concepts/protocol.mdx b/docs/guides/products/integrity/protocol.mdx → .../products/integrity/concepts/protocol.mdx
@@ -1,16 +1,18 @@
 ---
 title: 'Protocol'
-sidebar_position: 2
+sidebar_position: 1
 ---
 
-# Overview
+# Overview {#protocol-overview}
 
 This is an overview of the BLOOCK's Protocol and its technological stack. It's objective is to provide an introduction for developers to BLOOCK's technical stack. It also offers the approach to achieve high scalability. The explanation assumes you are familiar with the Ethereum ecosystem, the basic concepts of cryptography, and structures such as hashing and Merkle trees.
 
 ## First approach
 
 BLOOCK is a rollup solution that allows scaling data-tamper proofing on top of permissionless blockchain technologies. It uses blockchains for state storage but not for the computation of the aggregations, which is made internally with a specific frequency that depends on the network it is anchored to. The basic architecture of BLOOCK is simplified to ease understanding:
 
+![3 - Integrity](/static/docs/guides/integrity/3-integrity.png)
+
 ## Protocol
 
 BLOOCK manages an internal protocol that aggregates and consolidates messages to the L2 rollup with a certain time frequency. The messages received are queued internally between anchors in a pool of pending certificates. When the anchoring mechanism is executed, all the pending messages of the pool are included in the state chain of each client. A state chain is client independent and each client owns its chain of states. A genesis random hash forms the first block of each client state chain along with a set of certifications sent since the last confirmed anchor. From there on, the last client block root represents each block and all the certifications sent since the last confirmed anchor. Some may be wondering why is it necessary to separate each client message into independent shards. Mainly because of the following crucial points:
@@ -20,3 +22,5 @@ BLOOCK manages an internal protocol that aggregates and consolidates messages to
 - _**Right to be forgotten:**_ Any client in need to remove all certifications from BLOOCK State will be allowed to do so. BLOOCK will just keep the root of each of its blocks in the Rollup, which indeed has 0 links to the certifications sent thanks to the first block genesis hash.
 
 Once all client messages have been included in their respective state chains, the root of each new block created is appended to the BLOOCK Rollup stored by an only-append binary sparse Merkle tree. Once this action is finalized, we can conclude that all pending messages have been incorporated into the state of BLOOCK. Since we have a single shared state tree, BLOOCK can provide proofs that concatenate multiple certificates efficiently.
+
+![4 - Integrity](/static/docs/guides/integrity/4-integrity.png)
diff --git a/docs/guides/products/integrity/concepts/record-entity.mdx b/docs/guides/products/integrity/concepts/record-entity.mdx
@@ -0,0 +1,63 @@
+---
+title: 'Record entity'
+sidebar_position: 3
+---
+
+# The Record entity
+
+The principal element of the BLOOCK SDKs is the Record as it's used on most of the functionalities. It's responsible for different interactions such as:
+
+- Encapsulate your data
+- Hashing
+- Add [digital signatures](./../../key/overview.mdx#what-digital-signature)
+- Add [encryption](./../../key/concepts/operations.mdx#operations)
+- Add self-contained metadata
+
+### Record builders
+
+In order to generate a Record, our SDKs provide different builders to do so. Those builders enable to set as input different data types, formats or encodings based on your needs.
+
+#### Available builders
+
+Currently, the following builders are available:
+
+<table>
+  <thead>
+    <tr>
+      <th width="256">Name</th>
+      <th>Description</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>fromString</td>
+      <td>It takes a UTF-8 string as input</td>
+    </tr>
+    <tr>
+      <td>fromBytes</td>
+      <td>It takes an array of bytes as input</td>
+    </tr>
+    <tr>
+      <td>fromHex</td>
+      <td>
+        It takes a hash string (hex encoded 64-chars long string) as input
+      </td>
+    </tr>
+    <tr>
+      <td>fromJson</td>
+      <td>It takes a JSON as input</td>
+    </tr>
+    <tr>
+      <td>fromRecord</td>
+      <td>It takes a record as input</td>
+    </tr>
+    <tr>
+      <td>fromFile</td>
+      <td>It takes a file (as a byte array) as input</td>
+    </tr>
+    <tr>
+      <td>fromLoader</td>
+      <td>It takes a Loader as input</td>
+    </tr>
+  </tbody>
+</table>
diff --git a/docs/guides/products/integrity/features/_category_.json b/docs/guides/products/integrity/features/_category_.json
@@ -1,5 +1,5 @@
 {
-  "position": 4,
+  "position": 3,
   "label": "Features",
   "collapsible": true
 }
diff --git a/docs/guides/products/integrity/features/prepare-data.mdx b/docs/guides/products/integrity/features/prepare-data.mdx
@@ -3,77 +3,12 @@ title: 'Prepare data'
 sidebar_position: 1
 ---
 
-# Prepare data
+# Prepare data {#prepare-data}
 
 The first step of the certification process is to prepare the data that you want to certify through BLOOCK.
 
 This basically translates to load this data to the SDK, standardize it and compute a hash using the algorithm that BLOOCK uses internally (Keccak256). Luckily, all this process is done by the SDK internally so all you need to do is&#x20;
 
-## The Record entity
-
-The principal element of the BLOOCK SDKs is the Record as it's used on most of the functionalities. It's responsible for different interactions such as:
-
-- Encapsulate your data
-- Hashing
-- Add [digital signatures](broken-reference)
-- Add [encryption](broken-reference)
-- Add self-contained metadata
-
-### Record builders
-
-In order to generate a Record, our SDKs provide different builders to do so. Those builders enable to set as input different data types, formats or encodings based on your needs.
-
-#### Available builders
-
-Currently, the following builders are available:
-
-<table>
-  <thead>
-    <tr>
-      <th width="256">Name</th>
-      <th>Description</th>
-    </tr>
-  </thead>
-  <tbody>
-    <tr>
-      <td>fromString</td>
-      <td>It takes a UTF-8 string as input</td>
-    </tr>
-    <tr>
-      <td>fromBytes</td>
-      <td>It takes an array of bytes as input</td>
-    </tr>
-    <tr>
-      <td>fromHex</td>
-      <td>
-        It takes a hash string (hex encoded 64-chars long string) as input
-      </td>
-    </tr>
-    <tr>
-      <td>fromJson</td>
-      <td>It takes a JSON as input</td>
-    </tr>
-    <tr>
-      <td>fromRecord</td>
-      <td>It takes a record as input</td>
-    </tr>
-    <tr>
-      <td>fromFile</td>
-      <td>It takes a file (as a byte array) as input</td>
-    </tr>
-    <tr>
-      <td>fromLoader</td>
-      <td>
-        It takes a Loader as input (for more information check{' '}
-        <a data-mention href="broken-reference">
-          Broken link
-        </a>
-        )
-      </td>
-    </tr>
-  </tbody>
-</table>
-
 ## Examples
 
 import SdkCodeBlock from '/docs/partials/_sdk-code-block.mdx';

diff --git a/docs/guides/products/integrity/features/send-data.mdx b/docs/guides/products/integrity/features/send-data.mdx
@@ -5,12 +5,12 @@ sidebar_position: 2
 
 # Send data
 
-Once you have your [data prepared](prepare-data.md), you can send it to BLOOCK so it can be certified using our protocol.
+Once you have your [data prepared](./prepare-data.mdx#prepare-data), you can send it to BLOOCK so it can be certified using our protocol.
 
 When you send a new record to BLOOCK, it's queued internally and assigned to an Anchor. Once this Anchor is processed and transacted into the blockchain, the record gets certified and you will be able to verify it.
 
 :::tip
-The certification of a record may take some time to be confirmed. In order to manage this time interval, see [Synchronization](synchronization.mdx).
+The certification of a record may take some time to be confirmed. In order to manage this time interval, see [Synchronization](./synchronization.mdx#synchronization).
 :::
 
 ## Examples

diff --git a/docs/guides/products/integrity/features/synchronization.mdx b/docs/guides/products/integrity/features/synchronization.mdx
@@ -3,7 +3,7 @@ title: 'Synchronization'
 sidebar_position: 3
 ---
 
-# Synchronization
+# Synchronization {#synchronization}
 
 Once a data is sent for certification to BLOOCK, there's a time interval until it gets processed and transacted to the different blockchain networks. This time interval can be variable and, in some networks, pretty long,
 
@@ -43,7 +43,7 @@ Once a webhook is configured and a new anchor is processed for one of the select
 ## Synchronous
 
 :::tip
-`It's recommended to only use this method for networks with low internal times (<3 minutes)`
+It's recommended to only use this method for networks with low internal times (<3 minutes)
 :::
 
 It's also possible to wait for the interval in a synchronous manner by using our SDKs directly. This allows to keep a single code snippet that handles all the certification flow.&#x20;

diff --git a/docs/guides/products/integrity/features/verification.mdx b/docs/guides/products/integrity/features/verification.mdx
@@ -48,7 +48,7 @@ An integrity proof is a set of data computed by BLOOCK based on one (or more) Re
 Once an Integrity proof is computed it's valid over time. You can store it internally and use it for later verification to ensure full independence from our service from this point.
 
 :::tip
-You will not be able to verify a Record that is not fully processed and transacted to Blockchain. See [Syncronization](synchronization.md) for information about how to manage it.
+You will not be able to verify a Record that is not fully processed and transacted to Blockchain. See [Syncronization](./synchronization.mdx#syncronization) for information about how to manage it.
 :::
 
 Our SDKs allow to easily retrieve this integrity proof. Here are some code examples of how to implement it:
@@ -72,7 +72,7 @@ import GetProofGo from '!!raw-loader!@site/examples/integrity/get_proof/get_proo
 The next step in the verification process is to verify the integrity proof retrieved in the previous step. This is made by locally computing the result of the proof, which is the value (root) that, at some point of time, got transacted into blockchain.
 
 :::tip
-For more detail about this process, you can see the [Protocol](broken-reference) section.
+For more detail about this process, you can see the [Protocol](./../concepts/protocol.mdx#protocol-overview) section.
 :::
 
 All this process is managed by our SDKs and can be implemented as follows:
@@ -91,17 +91,9 @@ import VerifyProofGo from '!!raw-loader!@site/examples/integrity/verify_proof/ve
   go={VerifyProofGo}
 />
 
-### Validate digital signatures
-
-:::tip
-This step is only needed if a digital signature is detected in the Record's metadata. See the [Digital signature](broken-reference) section for more detail.
-:::
-
-This step is used to verify the authenticity of the Records (---)
-
 ### Validate in blockchain
 
-The last step of the verification process is to check if the output of the [Verify integrity proof](verification.md#verify-the-integrity-proof) step is actually in the selected blockchain network.
+The last step of the verification process is to check if the output of the [Verify integrity proof](./../concepts/integrity-proof-entity.mdx#integrity-proof-entity) step is actually in the selected blockchain network.
 
 This is made by querying the obtained root on the BLOOCK's Smart Contract deployed on each network available. The result of this query is a timestamp (specifically the block time) when this root was transacted into the network.
 

diff --git a/docs/guides/products/integrity/overview.mdx b/docs/guides/products/integrity/overview.mdx
@@ -3,22 +3,34 @@ title: 'Overview'
 sidebar_position: 1
 ---
 
-This section provides all the information needed to understand and integrate with BLOOCK's data certification service based on permissionless blockchains.
+BLOOCK's digital notarization service provides users with a secure and efficient means to notarize their information by sealing it to decentralized ledgers. Through this process, BLOOCK ensures the integrity, irrefutable timestamping, and verifiability of data across platforms.
 
-# Certification flow
+#### Key Features:
 
-In order to certify some data with BLOOCK, there are some steps that are happening, some of them need to be implemented by you (using our SDKs) and others are done by BLOOCK itself.
+1. **Seal to Decentralized Ledgers**: Notarize your information by securely sealing it to decentralized ledgers, guaranteeing its authenticity and immutability.
+2. **Scalability**: Scale up on-demand without the hassle of distributed ledger throughput constraints, allowing users to notarize large volumes of data seamlessly.
+3. **Accuracy**: Ensure the accuracy of your information without any limitations, with BLOOCK's system automatically normalizing and standardizing data to meet universal standards.
+4. **Cost-Efficiency**: Significantly diminish decentralized network costs, volatility, and uncertainties while remaining aligned with core principles, enabling cost-effective notarization solutions.
+5. **Universal Notarization**: Digitally notarize any type of information, regardless of its nature, with BLOOCK's system accommodating diverse data formats and ensuring compliance with universal standards.
 
-As a summary, you will need to implement only two parts:
+## The basics
 
-1. Prepare data
+### Certification flow
+
+To certify data with BLOOCK, the process involves several steps, some of which require implementation on your end using our SDKs, while others are handled by BLOOCK itself. Below is a summary of the certification flow:
+
+1. Prepare data:
 2. Send data
 3. Synchronization
 
-If you want more detail about the process, here's a diagram of all the certification process:
+Here's a diagram of the certification process:
+
+![1 - Integrity](/static/docs/guides/integrity/1-integrity.png)
+
+### Validation flow
 
-# Validation flow
+For the validation flow, verifying the authenticity and integrity of certified data involves a series of steps. These steps are detailed in the verification section of our documentation and can be implemented using examples provided. Additionally, we offer ready-to-use tools in the Validators section for those who prefer a more streamlined approach.
 
-For the verification flow, there are also some steps that need to be followed to implement it. It's all described with examples in the verification section and if you want some ready-to-use tools, see the Validators section for some options.
+Here's a diagram of the verification process:
 
-If you want more detail about the process, here's a diagram of all the verification process:
+![2 - Integrity](/static/docs/guides/integrity/2-integrity.png)
diff --git a/docs/guides/webhooks/concepts/_category_.json b/docs/guides/webhooks/concepts/_category_.json
@@ -0,0 +1,5 @@
+{
+  "position": 2,
+  "label": "Concepts",
+  "collapsible": true
+}