sprintertech
diff --git a/‎.yarnrc.yml
+1 b/‎.yarnrc.yml
+1
diff --git a/‎dictionary.txt
+93 b/‎dictionary.txt
+93
diff --git a/‎docs/01-introduction/01-index.md
+7-6 b/‎docs/01-introduction/01-index.md
+7-6
diff --git a/‎docs/02-sygma-protocol/01-index.md
+47 b/‎docs/02-sygma-protocol/01-index.md
+47
diff --git a/‎docs/02-sygma-protocol/02-Tailored-Security/01-index.md
+34 b/‎docs/02-sygma-protocol/02-Tailored-Security/01-index.md
+34
diff --git a/‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/02-mpc.md
+28 b/‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/02-mpc.md
+28
diff --git a/‎docs/03-architecture/05-security/01-Security-Intro.md renamed to ‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/03-tss.md
+6-6 b/‎docs/03-architecture/05-security/01-Security-Intro.md renamed to ‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/03-tss.md
+6-6
diff --git a/‎docs/03-architecture/05-security/02-peerdisc.md renamed to ‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/04-peerdisc.md
+4-4 b/‎docs/03-architecture/05-security/02-peerdisc.md renamed to ‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/04-peerdisc.md
+4-4
diff --git a/‎docs/03-architecture/05-security/03-keygen.md renamed to ‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/05-keygen.md
+4-4 b/‎docs/03-architecture/05-security/03-keygen.md renamed to ‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/05-keygen.md
+4-4
diff --git a/‎docs/03-architecture/05-security/04-signing.md renamed to ‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/06-signing.md
+4-4 b/‎docs/03-architecture/05-security/04-signing.md renamed to ‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/06-signing.md
+4-4
diff --git a/‎docs/03-architecture/05-security/05-keyreshare.md renamed to ‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/07-keyreshare.md
+4-4 b/‎docs/03-architecture/05-security/05-keyreshare.md renamed to ‎docs/02-sygma-protocol/02-Tailored-Security/02-MPC/07-keyreshare.md
+4-4
@@ -0,0 +1 @@
+nodeLinker: node-modules
@@ -367,9 +367,102 @@ Base-sepolia
 ERC1155TST
 sepolia
 ERC1155Handler
+sygma-core
+sygma-x-solidity
+zk
+Spectre
+spectre-node
+sygma-inclusion-prover
+prover
+sygma-widget
+Customizable
+sygma-explorer-indexer
+Veridise
 EVM-compatible
+Sygma-X-Solidity
+protocol-relayers
+tailoredsecurity
+tailoredsecurity-mpc-intro
+tss
+mpc-tss
+mpc-peerdisc
+mpc-keygen
+mpc-signing
+mpc-reshare
+EVM-compatible
+Amoy
+offchain
+tailoredsecurity-introduction
+modularized
+ZK
+spectre
+tailoredsecurity-spectre-intro
+coprocessor
+Gasper
+Spectre's
+Prover
+Verifier
+verifier
+Halo2
+halo2-lib
+auditability
+hardfork
+zipline
+tailoredsecurity-zipline-intro
 Amoy
 Blockops
 Veridise
 Spectre
 Sygma-X-Solidity
+resourceID
+MPC-specific
+Onchain
+Sygma-integrated
+MPC-verified
+Spectre-specific
+Spectre-verified
+evm
+protocol-evm
+DynamicERC20FeeHandlerEVM
+URI
+mb
+lr
+tradeoffs
+Sygma-specific
+L1
+middleware
+architected
+optionality
+zk-SNARK
+rollups
+Zipline's
+btc
+protocol-btc
+Tendermint-based
+subfield
+cryptosystem
+amongst
+decrypt
+ZKP
+rollup
+436H4jatj6ntHTVm3wh9zs1Mqa8p1ykfcdkNH7txmjmohTu3
+5EYCAe5jLbHcAAMKvLFSXgCTbPrLgBJusvPwfKcaKzuf5X5e
+Merkle
+sygma-widget-index
+customizable
+frontend
+Vite
+behaviour
+sygma-widget-lit
+codebase
+sygma-widget-react
+provers
+Gasper-based
+Validator
+eth
+holeskyETH
+incentivization
+domainID
+caip2
+caip19
+optionalities
@@ -13,11 +13,12 @@ Sygma is a fully open source ([Lesser General Public License version 3.0 (LGPL-3
 
 ## What's Next
 
-- Get started with our [Quick Start Guide](/docs/02-sygma-sdk/03-Quick-Start/01-installing-the-sdk.md)
-- Run your first [cross-chain token transfer](../02-sygma-sdk/03-Quick-Start/07-Examples/01-Basic-ERC-20-Token-Transfers/01-EVM-EVM-example.md)
-- Pass your first [generic message cross-chain](../02-sygma-sdk/03-Quick-Start/07-Examples/02-GMP-Examples/04-GMP-Example-With-A-Simple-Storage-Contract.md)
-- See the [environments](../06-environments/01-index.md) Sygma is deployed in
-- Look under the hood at the [architecture](../03-architecture/01-index.md)
+- Get started with our [Quick Start Guide](../03-sygma-sdk/01-index.md)
+- Run your first [cross-chain token transfer](../03-sygma-sdk/04-Examples/01-Basic-ERC-20-Token-Transfers/01-EVM-EVM-example.md)
+- Pass your first [generic message cross-chain](../03-sygma-sdk/04-Examples/02-GMP-Examples/01-GMP-Example-With-A-Simple-Storage-Contract.md)
+- See the [environments](../08-resources/01-environments/01-index.md) Sygma is deployed in
+- Look under the hood at the [architecture](../02-sygma-protocol/01-index.md)
+- Integrate the [Sygma Widget](https://sygma-react-widget.pages.dev/) into your dApp
 - Read more on the [Sygma Vision](02-origins.md)
 
-For the complete source code, please check out [Sygma's GitHub Repositories](../05-github-repositories.md). 
+For the complete source code, please check out [Sygma's GitHub Repositories](../08-resources/04-github-repositories.md). 
@@ -0,0 +1,47 @@
+---
+slug: /protocol
+id: protocol-index
+title: Sygma Protocol
+description: The following details the architecture of Sygma.
+---
+
+:::info
+The following sections detail the architectural components of the Sygma protocol.
+:::
+
+The Sygma interoperability protocol is able to transfer both tokens and arbitrary data. This allows developers and users to transfer ERC-20 tokens, ERC-721 tokens, ERC-1155 tokens, and **[Generic data](./06-generic.md).** Generic data can be used to bridge governance proposals or voting actions, for example, or any other contract call by transferring [calldata](https://ethereum.stackexchange.com/questions/52989/what-is-calldata).
+
+The Sygma protocol stack is designed to leverage the combined strength of both trusted and trustless verification systems. This ultimately forms a hybrid, trust-minimized system that facilitates secure communication and data exchange between blockchains driven by a user’s context and determined by tradeoffs around trust minimization, speed, and cost to transfer. Its modular design also facilitates its operation across any blockchain ecosystem and consensus mechanism with ease of integration. You can read more about this feature under [Tailored Security](./02-Tailored-Security/01-index.md).
+
+![](<../../static/assets/sygma_protocol_stack.png>)
+
+Sygma uses an offchain [relayer](./03-relayers.md) network to verify events on one chain that are to be posted to a destination chain. These relayer nodes, or agents, use a variety of verification systems to determine canon across chains. 
+
+Currently, the Sygma protocol is compatible with [EVM](../02-sygma-protocol/04-Supported-Ecosystems/01-evm.md) and [Substrate](../02-sygma-protocol/04-Supported-Ecosystems/02-substrate.md)-based networks (i.e. Polkadot and Kusama), but is proven to be easily extended to other networks such as Bitcoin and Tendermint-based chains (i.e. Cosmos).
+
+The below diagram describes a typical transfer flow within the Sygma protocol using MPC verification between two EVM-based networks: 
+
+![](<../../static/assets/Bridging Diagram.png>)
+
+## Configuring Sygma 
+
+Sygma utilizes a shared configuration file to enable cross-chain communications. It allows efficient management of network-specific parameters like `sygmaID`s, `chainID`s, and `sygmaResourceID`s. The shared config is primarily used by various components within the Sygma protocol, such as relayers, widgets, and SDK examples.
+
+- **`sygmaID`**: Formerly domainID, it refers to Sygma-specific identifiers ascribed to an L1 or L2 blockchain network. Most configurations in Sygma are domain-specific.
+
+- **`caipId`**: Representing [caip2](https://chainagnostic.org/CAIPs/caip-2) compatible domain identifier
+
+- **`ChainID`**: Represents the more conventionally understood identifiers denoting a blockchain network. It distinguishes between different networks within the same domain or across domains. It is primarily used during interactions with RPC endpoints. 
+
+- **`sygmaResourceID`**: Formerly resourceID, resources are Sygma-specific unique identifiers that define a token or an asset on a domain. It is crucial for asset tracking and management in cross-chain interactions. There can be different types, such as `fungible`, `nonfungible`, `semifungible`, `permissionlessgeneric`, etc.
+
+- **`caip19`**: Representing [caip19](https://chainagnostic.org/CAIPs/caip-19) compatible resource identifier
+
+- **`Asset`**: Refers to any token or digital resource managed on a blockchain within the Substrate framework. It can be native or bridged from another chain.
+
+- **`Handler` Types**: Describes the different types of handlers (e.g., `erc20`, `permissionlessGeneric`, etc.) available to a domain, and their roles in processing specific types of transactions or interactions within the network. For more on handlers, please see [Handlers](../02-sygma-protocol/04-Supported-Ecosystems/01-evm.md#handlers).
+
+- **`feeHandlers`**: Describes the fee strategies available on each domain. For more on fees, please see [Fees](../02-sygma-protocol/05-Fees/01-Fee-intro.md).
+
+<!-- - **`blockConfirmations`**: Under MPC relay, the block confirmations before an accepted attestation can be configured -->
+
@@ -0,0 +1,34 @@
+---
+slug: /protocol/tailoredsecurity
+id: tailoredsecurity-introduction
+title: Introduction To Tailored Security
+description: The following details Sygma's Tailored Security protocol
+---
+
+# What Is Tailored Security?
+
+Cross-chain use cases are advancing beyond just simply bridging assets. Interoperability now services complex interactions, from cross-chain contract execution to cross-chain liquid staking solutions, requiring the consensus of multiple verification systems to facilitate these. While the vast number of bridging solutions aim to enhance the trustworthiness and efficiency of cross-chain interoperability, most employ fixed security pathways, and none over aggregated tailored security routes. A true interoperability protocol should be able to adapt its verification mechanisms based on transaction type, assets involved, protocols of both chains, security, and cost requirements. The Sygma cross-consensus interoperability protocol achieves this through its architecture and application design, allowing users to select the optimal combinations of verification mechanisms based on their needs and input parameters.
+
+## Scenario
+
+Consider two scenarios: a gamer transferring their character NFT and a crypto whale liquidating a large stake. These examples, while targeting the same domains (source and destination chains), have so far been restricted to bridges that operate under a uniform security model with identical fees and latency. While this one-size-fits-all approach does technically get the job done, it often leads to dissatisfaction for at least one of the users and, in the worst case, for both.
+
+The above scenarios illustrate that a few key parameters must be considered when transacting cross-chain: *security* (high/low); *speed* (fast/slow); and *fees* (expensive/cheap). Additionally, considerations must be given to *asset type*, *amounts*, and even *market implications*.
+
+Building up from these principles, the Sygma protocol offers an alternative approach to securing cross-consensus interoperability: **Tailored Security**. It empowers users and developers to make optimal choices based on any given context. Sygma's Tailored Security leverages a multi-layered framework that combines **proof of authority**, **optimistic execution**, and **ZK proofs** to offer choice and flexibility to users. See [Verification Systems](#verification-systems) for more.
+
+Token routes between source and destination networks can be integrated with any one of these verification systems. Meanwhile, Sygma relayer nodes are equipped to handle and relay messages between chains no matter the framework selected.
+
+![](<../../../static/assets/tailoredsecurity_compare.png>)
+
+## Sygma's Verification Systems
+
+Sygma’s verification systems can be manually selected by the user or dynamically chosen by the protocol. Manual selection of verification system offers users flexibility and choice in security based on their context. Verification systems may also be dynamically chosen by a routing gateway as either a single or combined system. This balances degrees of trust minimization to offer appropriate levels of security. Below is a list of the verification systems available in the Sygma protocol: 
+
+- [**Multi-party computation (MPC)**](../02-Tailored-Security/02-MPC/02-mpc.md): a distributed set of relayers leveraging MPC to attest to the validity of transactions on a source chain, which then transmits the corresponding signed attestation to the destination chain.
+
+- [**Spectre**](../02-Tailored-Security/03-Spectre/01-spectre-intro.md): a trust-minimized zero knowledge (zk) light-client coprocessor that generates zk-SNARK proofs of source chain consensus and user-defined computation of the verified blockchain state that can be efficiently verified on the destination chain.
+
+- [**Zipline**](../02-Tailored-Security/04-Zipline/01-zipline-intro.md): a trust-minimized, gas-efficient, optimistic, fraud-proof verification system, which assumes transaction validity and offloads dispute verification to external challengers.
+
+The following documentation will dive into each verification system in detail. 
@@ -0,0 +1,28 @@
+---
+slug: /tailoredsecurity/mpc/intro
+id: tailoredsecurity-mpc-intro
+title: Multi-party Computation (MPC)
+description: The following details how MPC is utilized by Sygma.
+---
+
+:::info
+The following details Sygma's multi-party computation verification system.
+:::
+
+# Introduction To Sygma's Multi-party Computation (MPC)
+
+Sygma's Tailored Security system begins with its base **multi-party computation (MPC)** verification. For routes (i.e. source to destination chain) integrated with MPC, users and developers can enjoy a low cost, high speed, and secure service. At a high level, the verification system is implemented via 1) a set of MPC-specific contracts (or equivalent in other ecosystems) and 2) an MPC-specific relayer network.
+
+Onchain events are generated as a result of a cross-chain interaction (through a Sygma-integrated dApp). The MPC relayer network listens for and parses these cross-chain events. Multi-party computation methodologies are then used to determine whether these events are canonical; i.e. can it be verified that these events *actually* happened? The MPC relayer network will then make attestations and post these events to the destination chain, signifying the end of an MPC-verified cross-chain interaction. 
+
+## What Is Multi-party Computation?
+
+MPC represents a powerful next step in digital asset security because it eliminates the risk of a single point of compromise.
+
+Instead of relying on [Multisigs](https://en.wikipedia.org/wiki/Multisignature) or other, older ways of key management that either expose [relayer](../../03-relayers.md) identities or introduce easily exploitable single points-of-failure, relayers for Sygma run a secure MPC ceremony each time a user wishes to bridge funds or transfer arbitrary data. In this way, MPC enables multiple parties to carry out a distributed computation on their secret inputs without revealing anything but the output.&#x20;
+
+MPC was introduced as a solution for the **[Two Billionaires Problem](https://en.wikipedia.org/wiki/Yao%27s_Millionaires%27_problem)** (Bob and Alice; how to decide who is richer without showing their exact funds, a specific problem which is a Boolean predicate).
+
+The multi-party computation (MPC) model that Sygma employs includes a number of trusted relayer nodes operating under [a trusted federation](https://blog.chainsafe.io/bridges-in-crypto-space-12e158f5fd1e). These trusted relayer nodes are run by reputable entities in the web3 space.
+
+For a detailed research piece, please see [Multi-Party Computation: The Next Generation of Crypto Security](https://blog.buildwithsygma.com/multi-party-computation/) from our blog.
@@ -1,9 +1,9 @@
 ---
-slug: /readme/architecture/Security/intro
-id: Security-introduction
-title: Security
+slug: /tailoredsecurity/mpc/tss
+id: mpc-tss
+title: Threshold Signature Scheme
 description: The following details how Sygma addresses security concerns relating to various signature schemes.
-sidebar_position: 1
+sidebar_position: 2
 draft: false
 ---
 
@@ -14,13 +14,13 @@ draft: false
 
 ## Threshold Signature Schemes (TSS)
 
-**Threshold Signature Schemes (TSS)** is an area of [MPC](/docs/03-architecture/02-mpc.md) that is particularly useful for the crypto domain as it facilitates the distribution of a private key to multiple parties, introducing redundancy for assets management security.&#x20;
+**Threshold Signature Schemes (TSS)** is an area of [MPC](../../../02-sygma-protocol/02-Tailored-Security/02-MPC/02-mpc.md) that is particularly useful for the crypto domain as it facilitates the distribution of a private key to multiple parties, introducing redundancy for assets management security.&#x20;
 
 In other words, it enables a set of parties to perform certain cryptographic operations, like signing transactions, while none of them hold a full private key. Instead, the key is split across the parties, and it can only be used when a subset of those parties — the size of which is larger than a certain threshold — combine their key shares.
 
 ### An Example
 
-Imagine you have a secret key sk and [a special algorithm](03-keygen.md) that can divide this key into *n* pieces such that *[sk_i] = share_key(pk, n, t)*. Imagine now you want to [sign a transaction](04-signing.md) *m*, so you apply a similar algorithm to get partial signatures *[s_i] = sign(m, [sk_i])*. Now, to reconstruct a valid signature, you would simply sum all partial signatures together *s = s_0 + s_1 + … + s_i* and call it a day.
+Imagine you have a secret key sk and [a special algorithm](../../../02-sygma-protocol/02-Tailored-Security/02-MPC/05-keygen.md) that can divide this key into *n* pieces such that *[sk_i] = share_key(pk, n, t)*. Imagine now you want to [sign a transaction](../../../02-sygma-protocol/02-Tailored-Security/02-MPC/06-signing.md) *m*, so you apply a similar algorithm to get partial signatures *[s_i] = sign(m, [sk_i])*. Now, to reconstruct a valid signature, you would simply sum all partial signatures together *s = s_0 + s_1 + … + s_i* and call it a day.
 
 You might’ve also noticed a third argument *t* when we shared our key. Although the key is shared between *n* parties, we only need a threshold number of them to actually sign something. This is akin to a multisig scheme, which interestingly is just an emulation of threshold signatures using a high-level smart contract language like Solidity.
 
 
@@ -1,9 +1,9 @@
 ---
-slug: /readme/architecture/Security/peerdisc
-id: Security-peerdisc
+slug: /tailoredsecurity/mpc/peerdisc
+id: mpc-peerdisc
 title: Peer Discovery
 description: The following details the peer discovery process for all relayers.
-sidebar_position: 2
+sidebar_position: 3
 draft: false
 ---
 
@@ -25,4 +25,4 @@ Relayer nodes are deployed with a configuration in order to serve the above requ
 
 ## Flow
 
-  ![](<../../../static/assets/peerdisc_flow.png>)
+  ![](<../../../../static/assets/peerdisc_flow.png>)
@@ -1,9 +1,9 @@
 ---
-slug: /readme/architecture/Security/keygen
-id: Security-keygen
+slug: /tailoredsecurity/mpc/keygen
+id: mpc-keygen
 title: Key Generation
 description: The following details the key generation process for all relayers.
-sidebar_position: 3
+sidebar_position: 4
 draft: false
 ---
 
@@ -24,7 +24,7 @@ Ultimately, we can look on the key generation (i.e. keygen) as the access contro
 1. Admin calls `StartKeygen()` of `Bridge.sol` contract
 2. Event `KeygenRequired` is emitted by `Bridge.sol` contract
 3. Relayers that listen to events initiate `Keygen` protocol
-  ![](<../../../static/assets/keygen_flow.png>)
+  ![](<../../../../static/assets/keygen_flow.png>)
 4. Relayers observe chain state and listen to events that signal public key submission
 5. If public key *y* hasn’t been submitted yet, any one relayer can transact it onchain signaling the finalization of the protocol
 
 
@@ -1,9 +1,9 @@
 ---
-slug: /readme/architecture/Security/signing
-id: Security-signing
+slug: /tailoredsecurity/mpc/signing
+id: mpc-signing
 title: Proposal Signing
 description: The following details the signing of proposals by relayers.
-sidebar_position: 3
+sidebar_position: 5
 draft: false
 ---
 
@@ -20,7 +20,7 @@ After the key generation, each of *n* relayers has a key share *x* that will all
 1. User calls `deposit` method of `Bridge.sol` contract
 2. Event `Deposit` is emitted
 3. Relayers observe event `Deposit`, formulate message *M* and initiate `Keysign` protocol
-    ![](<../../../static/assets/keysign_flow.png>)
+    ![](../../../../static/assets/keysign_flow.png)
 4. Relayers observe chain state and listen to events of signature submission for the current proposal
 5. If signature *σ* hasn’t been submitted yet, any one relayer can transact it onchain signaling the finalization of the protocol
 
@@ -1,9 +1,9 @@
 ---
-slug: /readme/architecture/Security/reshare
-id: Security-reshare
+slug: /tailoredsecurity/mpc/reshare
+id: mpc-reshare
 title: Key Resharing
 description: The following details the process for key resharing.
-sidebar_position: 5
+sidebar_position: 6
 draft: false
 ---
 
@@ -42,4 +42,4 @@ Also note that during this procedure, the entire set of new relayers must be act
     4. go through Setup steps
 2. Admin checks whether new party is online and calls `adminAddRelayer()` of `Bridge.sol` which ends emitting `RelayerAdded` event
 3. All relayers including new ones initiate `Reshare` protocol
-  ![](<../../../static/assets/keyshare_flow.png>)
+  ![](<../../../../static/assets/keyshare_flow.png>)