Add safenet docs secured

.github/styles/config/vocabularies/default/accept.txt

@@ -202,6 +202,7 @@ Safe Module
 Safe Modules
 Safe [Ss]mart [Aa]ccount
 Safe Transaction Service
+Safenet
 Safe{Core} Account Abstraction SDK
 Safe{DAO}
 Sei
@@ -228,6 +229,7 @@ Telos
 Tenet
 ThunderCore
 Transaction Service
+Transciever
 U2U
 UI Kit
 Ultron

pages/_meta.json

@@ -3,6 +3,10 @@
     "title": "Home",
     "type": "page"
   },
+  "safenet": {
+    "title": "Safenet",
+    "type": "page"
+  },
   "sdk": {
     "title": "SDK",
     "type": "page"

pages/safenet/_meta.json

@@ -0,0 +1,24 @@
+{
+  "-- introduction": {
+    "type": "separator",
+    "title": "Introduction"
+  },
+  "overview": "Overview",
+  "introduction": "Why Safenet",
+  "chains": "Multi-Chain",
+  "architecture": "Architecture",
+  "safenet-account": "Safenet Account",
+  "safenet-transaction": "Safenet Transaction",
+  "optimistic-validity-proof": "Optimistic Validity Proof",
+  "-- details": {
+    "type": "separator",
+    "title": "Details"
+  },
+  "core-components": {
+    "type": "separator",
+    "title": "Core Components"
+  },
+  "concepts": "Concepts",
+  "protocol": "Protocol"
+}
+

pages/safenet/architecture.mdx

@@ -0,0 +1,24 @@
+# Architecture
+
+Safenet is a hybrid network that combines on-chain smart contracts across [multiple blockchains](./chains.mdx) and rollups with a decentralized network of off-chain actors that process transactions across these chains. 
+
+![Safenet-highlevel-overview](../../assets/safenet-highlevel-overview.png)
+
+Safenet is composed of the following key components:
+
+### Safe Smart Accounts
+Each Safenet Account is spread across multiple blockchains, with one Safe Smart Account per chain. 
+Every Safenet Account is anchored by a [Home Safe Smart Account](./protocol/home-safe.mdx) deployed on the Ethereum mainnet.
+
+### Safenet Smart Contracts
+These contracts are deployed on every supported chain, with the Ethereum mainnet as the primary hub for configuration and coordination.
+
+### Decentralized off-chain actors
+Safenet introduces several key roles for off-chain transaction processing:
+    * **[Processors](./core-components/processor.mdx)**: Handle the heavy lifting of processing, signing, and [settling](./concepts/settlement.mdx) [transactions](./safenet-transaction.mdx).
+    * **[Validators](./core-components/validator.mdx)**: Ensure the security and correctness of transactions by validating the work of processors.
+    * **[Liquidity Providers](./core-components/liquidity-provider.mdx)**: Supply liquidity on-chain to facilitate seamless transactions across different blockchains.
+
+### External Bridges
+External bridges are only used for dispute resolution when a validator challenges a Safenet transaction.
+

pages/safenet/chains.mdx

@@ -0,0 +1,33 @@
+# Multi-Chain
+
+Safenet provides a unified user experience over multiple blockchains.
+Safenet connects the liquidity of multiple chains, enabling users to spend their assets on any supported chain without the need for traditional bridging.
+A Safenet transaction can happen on one or multiple chains.
+In a [Safenet transaction](./safenet-transaction.mdx), chains can take up the following roles:
+
+![Safenet-chains](../../assets/safenet-chains.png)
+
+### Spend Chain
+
+This is where the user wants to execute an action.
+Safenet makes sure the required funds are available instantly on the spend chain.
+Another name is *target chain*.
+
+### Debit Chain
+
+This is where a user owns the required assets for the action.
+The user does not have to select the debit chain, as Safenet finds the required funds over all connected chains.
+Another name is *source chain*.
+
+### Home Chain
+
+Safenet uses Ethereum Mainnet as the home chain for configuration and coordination.
+For example, the configurable set of safety guarantees for a user's [Safenet account](./safenet-account.mdx) is stored on Ethereum Mainnet.
+
+## Chains vary per transaction
+
+For example, when a user wants to execute a transaction to spend funds on Optimism, while the funds are on Gnosis Chain, the spend chain will be Optimism, and the debit chain will be Gnosis Chain for this particular transaction.
+
+When a user wants to execute a transaction on the same chain where the funds are, the spend chain and debit chain are the same.
+
+Ethereum mainnet will always be Safenet's home chain.

pages/safenet/concepts/_meta.json

@@ -0,0 +1,8 @@
+{
+    "settlement": "Settlement",
+    "challenge": "Challenge",
+    "attestation": "Attestation",
+    "guarantee": "Guarantee",
+    "resource-lock": "Resource Lock",
+    "universal-balance": "Universal Balance"
+}

pages/safenet/concepts/attestation.mdx

@@ -0,0 +1,11 @@
+# Attestation
+
+The [processor](../core-components/processor.mdx) uses an attestation to prove the validity of a [settlement](../concepts/settlement.mdx).
+It serves as a cryptographic proof that the fulfillment of a Safenet [transaction](../safenet-transaction.mdx) is valid under the specific conditions defined by the user's configured [guarantees](../concepts/guarantee.mdx).
+
+The attestation has to be sent from the spend [chain](../chains.mdx) to the home chain, where it is validated by the [guarantee engine](../protocol/guarantee-engine.mdx).
+It is then sent from the guarantee engine to the [settlement engine](../protocol/settlement-engine.mdx) on the debit chain to finalize the settlement.
+The attestation data is sent through external bridges, which can be costly and slow.
+
+The processor has to provide the attestation when a [validator](../core-components/validator.mdx) [challenges](challenge.mdx) a [settlement](../concepts/settlement.mdx). 
+The processor can voluntarily provide the attestation with the settlement request to ensure the settlement is processed directly.

pages/safenet/concepts/challenge.mdx

@@ -0,0 +1,5 @@
+# Challenge
+
+A [validator](../core-components/validator.mdx) can challenge the [settlement](./settlement.mdx) request of a [processor](../core-components/processor.mdx). 
+In this case, the processor has to provide an [attestation](./attestation.mdx) to prove the validity of the [transaction](../safenet-transaction.mdx). 
+If the processor fails to provide the attestation, the settlement process is considered invalid, and the validator can slash the processor's stake to reimburse the [liquidity provider](../core-components/liquidity-provider.mdx).

pages/safenet/concepts/guarantee.mdx

@@ -0,0 +1,47 @@
+# Guarantee
+
+One of Safenet's core value propositions is the **enhanced security** it provides to users. 
+This security goes beyond the simple mechanisms of pre-funding and settlement; it is deeply embedded in Safenet's architecture through its **guarantee system**, which enforces specific conditions before transactions can be executed. 
+These guarantees protect users from various external risks, including hacks, phishing attacks, address poisoning, and other forms of fraud.
+
+Safenet introduces two types of guarantees, each serving a distinct purpose:
+
+## Core Guarantees
+
+Core guarantees are integral to Safenet's security model and form the foundation of the system. 
+They ensure the integrity of the pre-funding and settlement process, protecting users from malicious actors, such as a processor attempting to execute invalid transactions. 
+These guarantees are mandatory and automatically applied to all Safenet transactions.
+
+### Examples of core Guarantees
+
+- **Transaction Validity**: Ensures that all transactions executed by the processor are valid and follow the rules set by Safenet's validity-proof engine.
+- **Settlement Fraud Protection**: Enables validators to intervene if they detect fraudulent or incorrect transactions during the settlement process.
+
+## User-Configured Guarantees
+
+In addition to the mandatory core guarantees, Safenet allows users to enhance their security by customizing transaction rules through **user-configured guarantees**. 
+These guarantees offer additional protection against external threats, giving users more control over how and where their funds are sent.
+
+User-configured guarantees are optional and tailored to the user's specific needs. 
+They provide additional security layers that can be applied based on personal risk tolerance and transaction preferences.
+
+### Examples of User-Configured Guarantees
+
+- **Recipient Signature Enforcement**: Requires the recipient to sign a message before the transaction is executed, ensuring that funds are sent to the correct address (for example, to `0xb0b1` instead of a similar, malicious `0xbab1` address to prevent address poisoning).
+- **Account Type Restrictions**: Limits the transaction to approved types, such as externally owned accounts (EOA) or smart accounts, preventing funds from being sent to unknown or exotic accounts.
+- **Protocol Whitelisting**: Ensures that the transaction interacts only with trusted protocols, reducing the risk of sending funds to malicious or unverified contracts.
+- **Third-Party Approval**: Requires the transaction to be signed by a trusted third party (for example, [BlockAid](https://blockaid.xyz)) to protect against fraud.
+- **Spending Limits**: Enforces a daily spending limit, restricting the amount that can be transferred in a single transaction and providing protection against unauthorized large transfers.
+- **Address Book Validation**: Ensures that the recipient is part of an on-chain address book, adding another layer of verification to prevent sending funds to unintended recipients.
+
+If a processor executes a transaction that violates one of these guarantees (for instance, by sending funds to an incorrect address), the transaction can be challenged, and the user can be refunded. 
+This functions similarly to a chargeback on a credit card, where the lock on the funds is removed, and the transaction does not [settle](./settlement.mdx), leaving the user's funds in the account.
+
+## Technical details
+
+A guarantee is implemented by a [guarantee implementation](../protocol/guarantee-implementation.mdx), registered within the [Guarantee Engine](../protocol/guarantee-engine.mdx) on the Home Chain by the [SafeDAO](../protocol/safe-dao.mdx), and installed individually by an [end user](../core-components/end-user.mdx). 
+They prove that a Safenet transaction is valid under the specific conditions defined by the user's configured guarantees.
+
+Unlike atomic operations proven in a single Ethereum transaction, guarantees in Safenet are not necessarily atomic. 
+This allows for more complex guarantees, such as nested optimistic validity zero-knowledge (ZK) proofs, which can be used to ensure the validity of transactions in a more scalable and secure manner.
+

pages/safenet/concepts/resource-lock.mdx

@@ -0,0 +1,8 @@
+# Resource lock 
+
+The Resource Lock is a mechanism in Safenet that ensures the availability of user funds for transactions by locking a portion of the [End User's](../core-components/end-user.mdx) assets. 
+This lock guarantees that sufficient resources are set aside to [settle](./settlement.mdx) transactions securely and efficiently.
+
+The resource lock is issued on the funds on the debit [chain](../chains.mdx) before the fulfillment is done on the spend chain. The lock is maintained until the transaction is settled on the debit chain.
+
+The [processor](../core-components/processor.mdx) manages the resource lock, ensuring that no transactions can move funds out of the End User's Safe Smart Account on the debit chain while the resource lock is in effect.

pages/safenet/concepts/settlement.mdx

@@ -0,0 +1,136 @@
+import { Callout, Steps, Tabs } from 'nextra/components'
+
+# Settlement
+
+Settlement is the process by which a [processor](../core-components/processor.mdx) debits funds from a [Safenet account](../safenet-account.mdx) to repay the [liquidity provider](../core-components/liquidity-provider.mdx) for the short-term loan (pre-funding) used in a [Safenet transaction](../safenet-transaction.mdx).
+
+The [settlement engine](../protocol/settlement-engine.mdx) handles debit requests on the debit [chain](../chains.mdx) by transferring funds from the Safenet Safe to a [beneficiary](../protocol/beneficiary.mdx) designated by the liquidity provider. 
+This occurs after the liquidity provider has fronted funds on the spend chain.
+
+Once settlement is initiated, a delay period begins, during which [validators](../core-components/validator.mdx) can verify the settlement's correctness and challenge it if necessary. 
+If no challenge is made during this period, the processor completes the settlement, debiting the Safe and transferring the funds to the beneficiary, which includes repayment of the liquidity provision and relayer fees.
+
+If a validator [challenges](../concepts/challenge.mdx) the settlement, the cross-chain challenge process begins:
+
+## Challenge Process
+
+<Steps>
+
+### Challenge Initiation
+The validator initiates a transaction with the settlement engine to start a challenge on the debit chain, with a separate challenge delay. 
+During this delay, the processor must prove the settlement's correctness.
+
+### Correctness Proof
+The processor sends an [attestation](./attestation.mdx) from the spend chain (where the Safenet transaction was executed) to the home chain to validate the settlement.
+
+### Challenge Resolution
+The processor proves the settlement's validity to the guarantee engine on the home chain, which then informs the settlement contract on the debit chain:
+    * If the settlement is validated, the settlement can proceed immediately, bypassing the remaining settlement delay.
+    * If the processor fails to prove the settlement's validity, the challenge delay expires, and the settlement is deemed invalid, meaning it can never be executed. 
+
+When a challenge is successful, the processor or liquidity provider loses the fronted funds, and the user does not pay anything. 
+The user could benefit from the outgoing transaction.
+</Steps>
+
+
+## Flow Diagrams
+
+### Happy Flow
+
+```mermaid
+sequenceDiagram
+	box MVP Processor
+		actor P as Processor
+		actor LP as Liquidity Provider
+	end
+	actor V as Validator
+  participant S as Settlement Engine
+	participant A as Account
+
+  P->>S: settle (WITH COLLATERAL Ξ)
+  Note over S: Settlement Delay...
+  V->>V: check settlement correctness
+  Note over S: ...Settlement Delay
+  P->>+S: executeSettlement
+  A-->>LP: transferFrom(Account, Liquidity Provider)
+  deactivate S
+```
+
+The happy flow diagram illustrates the process of a successful settlement. 
+The processor initiates the settlement process by debiting the Safe and transferring funds to the beneficiary. 
+The validator verifies the settlement's correctness and, if no challenge is made, the settlement is completed.
+
+### Sad Flow
+
+```mermaid
+sequenceDiagram
+	box MVP Processor
+		actor P as Processor
+		actor LP as Liquidity Provider
+	end
+	actor V as Validator
+	box rgb(255,165,0,0.2)
+		participant G as Guarantee Engine<br>(HOME CHAIN)
+	end
+	participant B as Bridge
+  participant S as Settlement Engine
+	participant A as Account
+
+  P->>S: settle
+	Note over S: Settlement Delay...
+  V->>V: check settlement correctness
+
+  opt Incorrect Settlement
+	  V->>S: challenge (WITH COLLATERAL Ξ)
+	end
+
+  alt Correctness Proven
+    G-->>+B: correctnessProven
+	  B->>S: correctnessProven
+    A-->>LP: transferFrom(Account, Liquidity Provider)
+    deactivate B
+  else
+	  Note over S: ...Settlement Delay
+	  P-->>P: punished: loses fronted funds
+  end
+```
+
+The sad flow diagram illustrates the process of a failed settlement. 
+The validator challenges the settlement, and the processor must prove the settlement's validity. 
+If the processor fails to provide proof, the settlement is deemed invalid, and the funds are not transferred.
+
+### Correctness Proof (Attestation)
+
+```mermaid
+sequenceDiagram
+	box MVP Processor
+		actor P as Processor
+	end
+	box rgb(255,165,0,0.2)
+		participant E as Entry Point<br>(SPEND CHAIN)
+		participant S as Settlement Engine<br>(DEBIT CHAIN)
+	end
+	participant TS as Transceiver<br>for Spend Chain
+	participant TD as Transceiver<br>for Debit Chain
+	participant G as Guarantee Engine
+	participant G1 as Guarantee 1...
+	participant GN as ...Guarantee N
+
+  P->>+E: sendReceipt()
+  E-->>+TS: receipt
+  deactivate E
+  TS->>G: safenetReceipt()
+  deactivate TS
+
+  P->>+G: prove()
+  G->>G1: checkGuarantee()
+  G->>GN: checkGuarantee()
+  G->>-TD: correctnessProven()
+  TD-->>S: correctnessProven
+```
+
+The correctness proof diagram illustrates the process of proving the settlement's validity. 
+The processor sends information from the spend chain to the home chain, where the guarantee engine validates the settlement. 
+If the settlement is proven correct, the settlement can proceed immediately.
+
+The processor can voluntarily provide the attestation at the moment of settlement to bypass the challenge delay and ensure a faster settlement process.

pages/safenet/concepts/universal-balance.mdx

@@ -0,0 +1,9 @@
+# Universal Balance
+
+Universal Balance in Safenet refers to a unified account balance across multiple supported [blockchains](../chains.mdx). 
+It allows users to interact with any chain without manually bridging assets between chains.
+
+Rather than holding separate balances on each chain, the Universal Balance aggregates the user's funds across all chains and manages liquidity dynamically. 
+This enables chain abstraction, with the user spending from a single balance while the underlying system handles the complexities of settling funds on different chains.
+
+The Universal Balance simplifies user experience by removing the need for manual asset transfers and allowing instant liquidity access across chains.

pages/safenet/core-components/_meta.json

@@ -0,0 +1,5 @@
+{
+    "processor": "Processor",
+    "validator": "Validator",
+    "liquidity-provider": "Liquidity Provider"
+}

pages/safenet/core-components/end-user.mdx

@@ -0,0 +1,4 @@
+# End User
+
+The End User is an individual with one or more [Safenet accounts](../safenet-account.mdx), using [Safe\{Wallet\}](https://app.safe.global/welcome) to interact with Safenet.
+

pages/safenet/core-components/liquidity-provider.mdx

@@ -0,0 +1,3 @@
+# Liquidity Provider
+
+The Liquidity Provider supplies assets at a premium for [Safenet transactions](../safenet-transaction.mdx). They front the necessary funds and are reimbursed an additional fee during [settlement](../concepts/settlement.mdx).

pages/safenet/core-components/processor.mdx

@@ -0,0 +1,12 @@
+# Processor
+
+The Processor is a service that executes [transactions](../safenet-transaction.mdx) on behalf of the End User when specific conditions are met:
+
+* The [End User](./end-user.mdx) is registered with Safenet (locking assets through a [Guard](../protocol/guard.mdx) acting as a co-signing).
+* The End User has sufficient locked funds to settle transactions across one or more [chains](../chains.mdx).
+* The End User's [guarantees](../concepts/guarantee.mdx) are validated.
+* The Processor or [liquidity provider](./liquidity-provider.mdx) has enough liquidity to pre-fund the End User's account on the spend chain.
+
+After fulfillment, the Processor handles the [settlements](../concepts/settlement.mdx) by initiating an optimistic settlement process. 
+This process, subject to delay, can be [challenged](../concepts/challenge.mdx) by a [Validator](./validator.mdx). 
+The Processor refunds itself or the liquidity provider by pulling funds from the End User's account.

pages/safenet/core-components/safenet-protocol.mdx

@@ -0,0 +1,6 @@
+# Safenet Protocol
+
+The Safenet Protocol consists of smart contracts that enable trustless communication between all parties. 
+Both contract variables and events serve as communication channels. 
+
+The [Safenet Protocol](../protocol/overview.mdx) section documents the different smart contracts.

pages/safenet/core-components/transaction-service.mdx

@@ -0,0 +1,7 @@
+# Transaction Service
+
+The Transaction Service operates across all Safe-supported [chains](../chains.mdx) and indexes Safe Smart Accounts and transactions. 
+In Safenet, it functions as a **shared mempool**, recording transactions that the [processor](./processor.mdx) needs to execute.
+
+The Event Service works with the Transaction Service, triggering WebHooks for specific Safe events.
+