diff --git a/.yarnrc.yml b/.yarnrc.yml new file mode 100644 index 0000000..3186f3f --- /dev/null +++ b/.yarnrc.yml @@ -0,0 +1 @@ +nodeLinker: node-modules diff --git a/dictionary.txt b/dictionary.txt index f246e7a..d6d58be 100644 --- a/dictionary.txt +++ b/dictionary.txt @@ -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 \ No newline at end of file diff --git a/docs/01-introduction/01-index.md b/docs/01-introduction/01-index.md index 9803a0c..4af5243 100644 --- a/docs/01-introduction/01-index.md +++ b/docs/01-introduction/01-index.md @@ -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). \ No newline at end of file +For the complete source code, please check out [Sygma's GitHub Repositories](../08-resources/04-github-repositories.md). \ No newline at end of file diff --git a/docs/02-sygma-protocol/01-index.md b/docs/02-sygma-protocol/01-index.md new file mode 100644 index 0000000..917b0dd --- /dev/null +++ b/docs/02-sygma-protocol/01-index.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). + + + diff --git a/docs/02-sygma-protocol/02-Tailored-Security/01-index.md b/docs/02-sygma-protocol/02-Tailored-Security/01-index.md new file mode 100644 index 0000000..ca03655 --- /dev/null +++ b/docs/02-sygma-protocol/02-Tailored-Security/01-index.md @@ -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. \ No newline at end of file diff --git a/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/02-mpc.md b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/02-mpc.md new file mode 100644 index 0000000..8d29c65 --- /dev/null +++ b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/02-mpc.md @@ -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. + +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. diff --git a/docs/03-architecture/05-security/01-Security-Intro.md b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/03-tss.md similarity index 71% rename from docs/03-architecture/05-security/01-Security-Intro.md rename to docs/02-sygma-protocol/02-Tailored-Security/02-MPC/03-tss.md index 8acb95c..82ba0e7 100644 --- a/docs/03-architecture/05-security/01-Security-Intro.md +++ b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/03-tss.md @@ -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. +**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. 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. diff --git a/docs/03-architecture/05-security/02-peerdisc.md b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/04-peerdisc.md similarity index 88% rename from docs/03-architecture/05-security/02-peerdisc.md rename to docs/02-sygma-protocol/02-Tailored-Security/02-MPC/04-peerdisc.md index 11259e5..f0963c8 100644 --- a/docs/03-architecture/05-security/02-peerdisc.md +++ b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/04-peerdisc.md @@ -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>) \ No newline at end of file + ![](<../../../../static/assets/peerdisc_flow.png>) \ No newline at end of file diff --git a/docs/03-architecture/05-security/03-keygen.md b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/05-keygen.md similarity index 93% rename from docs/03-architecture/05-security/03-keygen.md rename to docs/02-sygma-protocol/02-Tailored-Security/02-MPC/05-keygen.md index 9edaf69..0c8a2ba 100644 --- a/docs/03-architecture/05-security/03-keygen.md +++ b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/05-keygen.md @@ -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 diff --git a/docs/03-architecture/05-security/04-signing.md b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/06-signing.md similarity index 89% rename from docs/03-architecture/05-security/04-signing.md rename to docs/02-sygma-protocol/02-Tailored-Security/02-MPC/06-signing.md index 53d8615..ce22a77 100644 --- a/docs/03-architecture/05-security/04-signing.md +++ b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/06-signing.md @@ -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 diff --git a/docs/03-architecture/05-security/05-keyreshare.md b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/07-keyreshare.md similarity index 95% rename from docs/03-architecture/05-security/05-keyreshare.md rename to docs/02-sygma-protocol/02-Tailored-Security/02-MPC/07-keyreshare.md index 4699fce..e9eb6cf 100644 --- a/docs/03-architecture/05-security/05-keyreshare.md +++ b/docs/02-sygma-protocol/02-Tailored-Security/02-MPC/07-keyreshare.md @@ -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>) diff --git a/docs/02-sygma-protocol/02-Tailored-Security/03-Spectre/01-spectre-intro.md b/docs/02-sygma-protocol/02-Tailored-Security/03-Spectre/01-spectre-intro.md new file mode 100644 index 0000000..6e0e906 --- /dev/null +++ b/docs/02-sygma-protocol/02-Tailored-Security/03-Spectre/01-spectre-intro.md @@ -0,0 +1,67 @@ +--- +slug: /tailoredsecurity/spectre/intro +id: tailoredsecurity-spectre-intro +title: Introduction To Spectre +description: The following details how Spectre is utilized by Sygma. +draft: false +--- + +:::info +The following details Sygma's Spectre verification system utilizing zero-knowledge (zk) proofs of consensus between EVM domains. Spectre was developed by ChainSafe as a set of zk cryptographic provers, arithmetic circuits, and contracts. Protocol Sygma integrates Spectre, along with custom infrastructure built to utilize Spectre, to provide zk verification. For ease of definition, this verification system will be generally referred to as "Spectre", but there are distinctions between components built for Sygma and cryptographic components built for Spectre. +::: + +# Introduction To Sygma's Spectre + +Sygma's **zero knowledge (zk) light client coprocessor, Spectre**, offers a trust-minimized, highly secure verification system that brings high speeds and low cost (at scale) in zk verification to EVM-based environments. At a high level, the verification system is implemented via 1) a set of Spectre-specific contracts (or equivalent in other ecosystems), including SNARK verifier contracts; 2) a Spectre-specific relayer + Spectre prover, and 3) a Sygma inclusion prover. + +The Spectre _relayer_, upon detection of an onchain event, requests the Spectre _prover_ to generate a zk-SNARK proof of the source chain state root / block header. The relayer then submits this proof onchain to a proxy contract acting as the state root storage. This triggers the executor contract on the destination chain. A separate offchain inclusion prover must then submit Merkle proofs of transaction/state inclusion in the verified + finalized canonical source chain block to the executor contract. If valid, the execution will then be posted to the destination chain, signifying the end of a Spectre-verified cross-chain interaction. + +![](<../../../../static/assets/sygma_spectre_flow.png>) + +## What Is Spectre? + +Spectre implements a blockchain coprocessor to offload intensive computations from a constrained onchain execution layer to a more expansive offchain environment. Its purpose is to produce succinct proofs of [Gasper](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/gasper/) consensus that can be efficiently verified on a destination chain. + +This model stands in contrast to the prevailing approach where a committee of relayers post a [signature](../02-MPC/06-signing.md) (generated via [MPC](../02-MPC/02-mpc.md)) stating that the majority of them have detected a certain onchain event. It's crucial to note that neither the threshold signature nor its generation process is concerned with specific consensus rules — they merely confirm the signer's assertions. + +In contrast, the coprocessor proofs are tailored to the exact computations being verified. Therefore, no valid proof can exist for a computation that halts, for instance, due to fraudulent inputs. Spectre’s coprocessor proofs are cryptographic arguments of knowledge, or **SNARK**s (Succinct, Non-Interactive Arguments of Knowledge). A critical aspect of Spectre is that it does not rely on trusted intermediaries and makes no probabilistic economic assumptions. + +It may be helpful to separate the components native to Spectre and the components built by Sygma in order to utilize Spectre. + +Spectre consists of three main components: +- **Spectre Prover** +- **Light-client Circuits** +- **Spectre Contracts** + - **Verifier contract** + - **Light client handler contract** + +Sygma-specific components: +- **Relayer** +- **Inclusion prover** +- **Sygma contracts** + +## Spectre Prover + +The prover generates a zero-knowledge proof by performing the necessary computations without revealing any information apart from the validity of a statement. This component utilizes a fork of the [Halo2 proving stack](https://github.com/privacy-scaling-explorations/halo2). + +Two types of proofs are submitted onchain: +- Step Proofs + - These are submitted only for the epoch where a cross-chain interaction is detected by a Sygma relayer. However, depending on the implementation, such as in the case of a Mainnet -> Gnosis route, step proofs are generated every epoch (~3 minutes). +- Rotate Proofs + - These are submitted every 256 epoch (or ~27 hours on Ethereum) in order to follow Altair sync committee rotations. + +:::info +A more general definition for `epoch` for different Gasper-based source chains: +- Ethereum mainnet = 12 seconds * 32 slots = ~6.5 minutes +- Gnosis = 5 seconds * 32 slots = ~3 minutes +::: + +## Light-client Circuits + +Circuits in the context of ZK proofs refers to the arithmetic circuit that defines the computation being proved. These circuits are a way to describe computations in terms that are suitable for cryptographic proofs. In Spectre, circuits are implemented using the [halo2-lib](https://github.com/axiom-crypto/halo2-lib) circuit development framework, which ensures that the circuits are both efficient and secure. The circuits specify the series of arithmetic operations that the prover must perform to generate a valid proof. For Spectre, these circuits specifically handle operations related to verifying the Ethereum Altair Light Client protocol. This library contains a number of non-trivial optimization tricks, while its readable SDK prevents most of the soundness bugs and improves auditability. + +![](<../../../../static/assets/spectre_lightclient_benchmark.png>) + +## Verifier Contract + +"Verifier Contracts" are smart contracts deployed on a blockchain that verify the consensus proofs submitted by the prover. These contracts contain the logic necessary to validate the inclusion of transactions in a block that was finalized on the source chain - without having to redo the computation. In Spectre, these contracts are auto-generated and can handle proofs related to the consensus rules of the Ethereum blockchain as modified by the [Altair hardfork](https://ethereum.org/en/history/#altair). The verifier contract checks the proof provided by the prover using only a small amount of data and confirms whether the proof is correct, thereby ensuring that the computation was performed accurately and without tampering. \ No newline at end of file diff --git a/docs/02-sygma-protocol/02-Tailored-Security/04-Zipline/01-zipline-intro.md b/docs/02-sygma-protocol/02-Tailored-Security/04-Zipline/01-zipline-intro.md new file mode 100644 index 0000000..e6f1862 --- /dev/null +++ b/docs/02-sygma-protocol/02-Tailored-Security/04-Zipline/01-zipline-intro.md @@ -0,0 +1,37 @@ +--- +slug: /tailoredsecurity/zipline/intro +id: tailoredsecurity-zipline-intro +title: Introduction To Zipline +description: The following details how Zipline is utilized by Sygma. +draft: false +--- + +:::info +The following details Sygma's Zipline (Optimistic fraud proof) verification system. +::: + +# Introduction To Zipline + +**Zipline** is a gas-efficient, optimistic, fraud-proof verification system, which _optimistically_ assumes transaction validity and offloads dispute verification to external challengers. It is the third verification system in Sygma's Tailored Security protocol stack. It provides a high speed, low cost, and highly secure verification mechanism - when immediate finality is not required. + +## Cross-chain Fault Proofs + +The Zipline protocol allows anyone to submit updates, provided that they supply a bond (a security deposit). These updates are subject to a challenge period (7 days), during which anyone can dispute their validity. If a dispute arises, a game begins to identify where potential fraud may have occurred. + +This process uses a technique called [bisection](https://en.wikipedia.org/wiki/Bisection_method?ref=blog.buildwithsygma.com) of the [execution trace](https://www.risczero.com/docs/explainers/proof-system/what_is_a_trace?ref=blog.buildwithsygma.com) to pinpoint the suspicious instruction, which the chain then executes to determine if there was fraud. + +Zipline functions similarly to optimistic rollups like Optimism and Arbitrum with one key difference: instead of processing and posting transactions, it verifies the _finality_ of another chain. + +## Design Overview + +Zipline’s implementation is inspired by [Optimism’s Cannon stack](https://docs.optimism.io/stack/protocol/fault-proofs/cannon). It has been adopted for cross-chain interoperability by focusing on the correctness of finality attestations verification — the stage where a block or a set of transactions has been confirmed as final and cannot be reverted under normal network conditions. Zipline allows anyone to submit updates, provided that they supply a bond (economic security). These updates are subject to a challenge period (7 days), during which anyone can dispute their validity. If a dispute arises, a process of comparing two results (a bisection game) begins, verifying and pinpointing the suspicious instruction. If a challenge is unsuccessful, the bond is forfeited. + +Zipline functions similar to fault-proof-based rollups like Optimism and Arbitrum, which assume transactions are correct unless proven otherwise. However, rather than processing transactions, Zipline verifies the finality on the destination chain. By doing so, it effectively acts as a verifier or auditor of the destination chain’s finality protocol, checking for correctness and integrity, enabling the path for new and efficient cross-chain use cases for further interoperability. + +## Economic Security + +While Zipline accepts permissionless proposals for candidate finalized blocks, it utilizes economic security as an additional layer of defense. Each proposal must be accompanied by a bond, which acts as a financial incentive to align a participant’s behavior with the network’s goals and deter any malicious intentions. If a proposal goes unchallenged within the dispute period, the proposal is +considered final, and the bond is returned. + +In the event an observer believes a proposal to be fraudulent, they are eligible to submit a fraud proof on the destination chain within the dispute period to challenge the validity of the transaction. In the context of a cross-chain transaction, this could be a claim that assets on the source chain were not correctly locked or burned prior to bridging to the destination chain. In all optimistic implementations, it is guaranteed that the honest party will prevail. In Zipline’s implementation, a +proven fraud proof will revert the block root and slash the bond of the malicious proposer, and award it to the challenger. \ No newline at end of file diff --git a/docs/02-sygma-protocol/02-Tailored-Security/_category_.json b/docs/02-sygma-protocol/02-Tailored-Security/_category_.json new file mode 100644 index 0000000..293c41e --- /dev/null +++ b/docs/02-sygma-protocol/02-Tailored-Security/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Tailored Security", + "position": 1 + } \ No newline at end of file diff --git a/docs/02-sygma-protocol/03-relayers.md b/docs/02-sygma-protocol/03-relayers.md new file mode 100644 index 0000000..e8bf0aa --- /dev/null +++ b/docs/02-sygma-protocol/03-relayers.md @@ -0,0 +1,36 @@ +--- +slug: /protocol/relayers +id: protocol-relayers +title: Relayers +description: The following details how relayers are defined and managed by Sygma. +--- + +:::info +The following details how relayers are defined and managed by Sygma. +::: + +_Relayers are entities that ensure bridge decentralization and execute asset and message bridging._ + +At the core of Sygma exists a **set of relayers**. Relayers are offchain middleware agents whose responsibility is to listen and parse for source chain events. Upon verification of canon on the source chain (either through attestation, proof of computation, or optimistic relay), the relayer network posts to the destination network. + +Under the [tailored security](../02-sygma-protocol/02-Tailored-Security/01-index.md) protocol, separate relayers exist for the various verification mechanisms. + +## MPC Relay + +For MPC relay, the relayer network is distributed among several legal entities and operate under a trusted federation model. Spreading the relayer set across several legal entities creates a distribution of responsibilities and mitigates risk by disincentivizing relayers in the set to act in an unfair manner. + +Each relayer within the set listens to both the source and destination chains that are being bridged by Sygma. Based on events that are emitted, these relayers then execute relevant actions. + +This multi-relayer set is responsible for relaying messages from a source network to a destination network. Relayers are operating with private key share and execution happens on the destination network with the [MPC](../02-sygma-protocol/02-Tailored-Security/02-MPC/02-mpc.md) private key. + +Communication between relayer parties happens in a [p2p](https://en.wikipedia.org/wiki/Peer-to-peer) manner; and participants of [p2p](https://en.wikipedia.org/wiki/Peer-to-peer) and MPC communication are strictly defined by a configuration file, which allows us to prevent [Sybil Attacks](https://en.wikipedia.org/wiki/Sybil\_attack). + +For more on our current list of relayer partners or learn how to become one, please see [Becoming A Relayer Partner](../04-integrating-with-sygma/05-relayer-partner.md). + +## Spectre + +More details coming soon + +## Zipline + +More details coming soon \ No newline at end of file diff --git a/docs/02-sygma-protocol/04-Supported-Ecosystems/01-evm.md b/docs/02-sygma-protocol/04-Supported-Ecosystems/01-evm.md new file mode 100644 index 0000000..1ef3313 --- /dev/null +++ b/docs/02-sygma-protocol/04-Supported-Ecosystems/01-evm.md @@ -0,0 +1,32 @@ +--- +slug: /protocol/ecosystem/evm +id: protocol-evm +title: EVM Support +description: The following details EVM support on Sygma. +--- + +:::info +The following section details Sygma's compatibility with EVM chains via its ecosystem of smart contracts. +::: + +Sygma uses Solidity smart contracts to enable transfers to and from Ethereum Virtual machine (EVM) compatible chains. These contracts consist of a core bridge contract (`Bridge.sol`), and a set of handler contracts (e.g. `ERC20Handler.sol`, `ERC721Handler.sol`, `PermissionlessGenericHandler.sol`, `FeeHandlerRouter.sol`, `BasicFeeHandler.sol`). [Different verification systems](../02-Tailored-Security/01-index.md) also require separate sets of smart contracts. These onchain components establish a relationship with the offchain actors via generation and detection of onchain contract events. + +## Sygma's Smart Contracts + +### Bridge + +The bridge contract is responsible for initiating and executing proposed transfers. It facilitates and manages cross-chain transfer of assets and messages by recording and verifying `deposit`, `executeProposals`, and other cross-chain events. The actual handling of the deposits/withdrawals is handled by the appropriate handler contracts. The `Bridge.sol` contract serves as the primary gateway for a cross-chain interaction. + +### Handlers + +The handlers are used by the bridge contract to interact with other existing contracts. For example, the `ERC20Handler` contract handles fungible ERC-20 tokens, enabling their deposit, withdrawal, and management within the protocol. On the other hand, the `PermissionlessGenericHandler` contract processes generic message deposits and their execution. It is designed to handle complex data encoding for executing transactions across chains. + +Beyond contracts handling asset/message types, there are handler contracts that route fees (`FeeHandlerRouter`) and collect/manage fees (`BasicFeeHandler`, `PercentageFeeHandler`) based on the destination domain `sygmaID` and `sygmaResourceID` (see [Configuring Sygma](../01-index.md#configuring-sygma)). + +For more information on both the Bridge and Handler contracts, please visit the [sygma-solidity](https://github.com/sygmaprotocol/sygma-solidity) repo. + +### Spectre + +Sygma's zk verification system, [Spectre](../02-Tailored-Security/03-Spectre/01-spectre-intro.md), implements a separate set of smart contracts, including the Bridge and Handler contracts discussed previously. Additionally, Spectre implements Spectre-specific smart contracts such as `Spectre`, the `SpectreProxy`, `AccessControlSegregator`, `Router`, and `Executor`. Crucially, the `Spectre` and `SpectreProxy` contracts follow Ethereum's sync committee rotations, allowing lightweight verification of source computation. On the other hand, the `Executor`contract is responsible for receiving 1) block header zk-SNARK proofs from the offchain Spectre relayer node and 2) execution submissions and inclusion proofs from the offchain inclusion prover, and then finally 3) "executing" on a cross-chain interaction. + +For more information on these contracts, please visit the [sygma-x-solidity](https://github.com/sygmaprotocol/sygma-x-solidity) repo. \ No newline at end of file diff --git a/docs/03-architecture/07-substrate.md b/docs/02-sygma-protocol/04-Supported-Ecosystems/02-substrate.md similarity index 97% rename from docs/03-architecture/07-substrate.md rename to docs/02-sygma-protocol/04-Supported-Ecosystems/02-substrate.md index 10ba5f6..eb22b91 100644 --- a/docs/03-architecture/07-substrate.md +++ b/docs/02-sygma-protocol/04-Supported-Ecosystems/02-substrate.md @@ -1,6 +1,6 @@ --- -slug: /architecture/substrate -id: architecture-substrate +slug: /protocol/ecosystem/substrate +id: protocol-substrate title: Substrate Support description: The following details Substrate support on Sygma. --- @@ -17,7 +17,7 @@ Similar to how Sygma enables EVM support by invoking various smart contracts, Sy Substrate pallets provide a modular approach to building Substrate-based blockchains and contain runtime logic which can be used, modified, and extended accordingly. ::: -![](<../../static/assets/Substrate __ EVM.png>) +![](../../../static/assets/Substrate%20__%20EVM.png) --- diff --git a/docs/02-sygma-protocol/04-Supported-Ecosystems/03-btc.md b/docs/02-sygma-protocol/04-Supported-Ecosystems/03-btc.md new file mode 100644 index 0000000..97b4b92 --- /dev/null +++ b/docs/02-sygma-protocol/04-Supported-Ecosystems/03-btc.md @@ -0,0 +1,7 @@ +--- +slug: /protocol/ecosystem/btc +id: protocol-btc +title: Bitcoin Support +description: The following details Bitcoin support on Sygma. +draft: true +--- \ No newline at end of file diff --git a/docs/02-sygma-protocol/04-Supported-Ecosystems/04-cosmos.md b/docs/02-sygma-protocol/04-Supported-Ecosystems/04-cosmos.md new file mode 100644 index 0000000..3d8bea1 --- /dev/null +++ b/docs/02-sygma-protocol/04-Supported-Ecosystems/04-cosmos.md @@ -0,0 +1,7 @@ +--- +slug: /protocol/ecosystem/cosmos +id: protocol-cosmos +title: Cosmos Support +description: The following details Cosmos support on Sygma. +draft: true +--- \ No newline at end of file diff --git a/docs/02-sygma-protocol/04-Supported-Ecosystems/_category_.json b/docs/02-sygma-protocol/04-Supported-Ecosystems/_category_.json new file mode 100644 index 0000000..6e3e69d --- /dev/null +++ b/docs/02-sygma-protocol/04-Supported-Ecosystems/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Supported Ecosystems", + "position": 4 + } + \ No newline at end of file diff --git a/docs/03-architecture/03-Fees/01-Fee-intro.md b/docs/02-sygma-protocol/05-Fees/01-Fee-intro.md similarity index 53% rename from docs/03-architecture/03-Fees/01-Fee-intro.md rename to docs/02-sygma-protocol/05-Fees/01-Fee-intro.md index b91060e..ae08d62 100644 --- a/docs/03-architecture/03-Fees/01-Fee-intro.md +++ b/docs/02-sygma-protocol/05-Fees/01-Fee-intro.md @@ -1,6 +1,6 @@ --- -slug: /architecture/fees/Fee-intro -id: architecture-Fee-intro +slug: /protocol/fees/Fee-intro +id: protocol-Fee-intro title: Introduction To Fees description: The following details how fees are handled by Sygma. sidebar_position: 1 @@ -29,6 +29,31 @@ The Sygma protocol allows for two fee strategies, implemented via **fee handlers ![](../../../static/assets/fee-router-general.png) +These fee handlers are mapped between `sygmaResourceID` and the handler address. This logic can be found in the `Bridge.sol` mapping called `_resourceIDToHandlerAddress`: + +```solidity +mapping(bytes32 => address) public _resourceIDToHandlerAddress; + +function adminSetResource(address handlerAddress, bytes32 resourceID, address contractAddress, bytes calldata args) external onlyAllowed { + _resourceIDToHandlerAddress[resourceID] = handlerAddress; + IHandler handler = IHandler(handlerAddress); + handler.setResource(resourceID, contractAddress, args); +} +``` + +In Substrate, the `FeeHandlersRouter` handles the configuration of fee routes. The `adminSetResourceHandler` function is used to set up routes for specific `sygmaResourceID`s and destination domains: + +```rs +decl_module! { + pub struct Module for enum Call where origin: T::Origin { + #[weight = 10_000] + pub fn admin_set_resource_handler(origin, destination_domain: u32, resource_id: Vec, handler_id: u32) -> DispatchResult { + ensure_root(origin)?; + ::insert((destination_domain, resource_id), handler_id); + Ok(()) + } +``` + ### Fee Collection -Fees are usually collected in the source (i.e. native) token, but can be collected in any token using a [percentage-based fee strategy](04-Percentage-Based-Fee.md) is selected. If you are interested in a custom fee setup, please contact us on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x). \ No newline at end of file +Fees are usually collected in the source (i.e. native) token, but can be collected in any token using a [percentage-based fee strategy](04-Percentage-Based-Fee.md). If you are interested in a custom fee setup, please contact us on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x). \ No newline at end of file diff --git a/docs/03-architecture/03-Fees/02-Fixed-Fee.md b/docs/02-sygma-protocol/05-Fees/02-Fixed-Fee.md similarity index 94% rename from docs/03-architecture/03-Fees/02-Fixed-Fee.md rename to docs/02-sygma-protocol/05-Fees/02-Fixed-Fee.md index 5d2c0f7..663d6b7 100644 --- a/docs/03-architecture/03-Fees/02-Fixed-Fee.md +++ b/docs/02-sygma-protocol/05-Fees/02-Fixed-Fee.md @@ -1,6 +1,6 @@ --- -slug: /architecture/fees/fixed -id: architecture-fixed +slug: /protocol/fees/fixed +id: protocol-fixed title: Fixed Fee Strategy description: The following section details how fixed fee strategies work in Sygma. sidebar_position: 2 diff --git a/docs/03-architecture/03-Fees/03-dynamic-fee.md b/docs/02-sygma-protocol/05-Fees/03-dynamic-fee.md similarity index 93% rename from docs/03-architecture/03-Fees/03-dynamic-fee.md rename to docs/02-sygma-protocol/05-Fees/03-dynamic-fee.md index 1c588b5..02fc9a8 100644 --- a/docs/03-architecture/03-Fees/03-dynamic-fee.md +++ b/docs/02-sygma-protocol/05-Fees/03-dynamic-fee.md @@ -1,6 +1,6 @@ --- -slug: /architecture/fees/dynamic -id: architecture-dynamic +slug: /protocol/fees/dynamic +id: protocol-dynamic title: Dynamic Fee Strategy description: The following section details how dynamic fee strategies work in Sygma. sidebar_position: 3 @@ -44,5 +44,5 @@ This information is used to determine the cost of transactions on the destinatio :::info The fee oracle service will be _centralized_ in the beginning. -The current architecture implies a future update of the fee oracle to a more decentralized or trustless solution. However, since the calculated fee is visible and approved by the user, the current fee oracle does not pose a [security](../05-security/01-Security-Intro.md) threat to the entire system. +The current architecture implies a future update of the fee oracle to a more decentralized or trustless solution. However, since the calculated fee is visible and approved by the user, the current fee oracle does not pose a [security](../02-Tailored-Security/02-MPC/03-tss.md) threat to the entire system. ::: diff --git a/docs/03-architecture/03-Fees/04-Percentage-Based-Fee.md b/docs/02-sygma-protocol/05-Fees/04-Percentage-Based-Fee.md similarity index 95% rename from docs/03-architecture/03-Fees/04-Percentage-Based-Fee.md rename to docs/02-sygma-protocol/05-Fees/04-Percentage-Based-Fee.md index e580dba..4b2eade 100644 --- a/docs/03-architecture/03-Fees/04-Percentage-Based-Fee.md +++ b/docs/02-sygma-protocol/05-Fees/04-Percentage-Based-Fee.md @@ -1,6 +1,6 @@ --- -slug: /architecture/fees/percentage -id: architecture-percentage +slug: /protocol/fees/percentage +id: protocol-percentage title: Percentage-based Fee Strategy description: The following section details how percentage-based fee strategies work in Sygma. sidebar_position: 4 diff --git a/docs/03-architecture/03-Fees/_category_.json b/docs/02-sygma-protocol/05-Fees/_category_.json similarity index 58% rename from docs/03-architecture/03-Fees/_category_.json rename to docs/02-sygma-protocol/05-Fees/_category_.json index 1aee922..440024e 100644 --- a/docs/03-architecture/03-Fees/_category_.json +++ b/docs/02-sygma-protocol/05-Fees/_category_.json @@ -1,4 +1,4 @@ { "label": "Fees", - "position": 1 + "position": 5 } diff --git a/docs/03-architecture/06-generic.md b/docs/02-sygma-protocol/06-generic.md similarity index 97% rename from docs/03-architecture/06-generic.md rename to docs/02-sygma-protocol/06-generic.md index 8ad4d2f..4bebfd1 100644 --- a/docs/03-architecture/06-generic.md +++ b/docs/02-sygma-protocol/06-generic.md @@ -1,6 +1,6 @@ --- -slug: /architecture/generic -id: architecture-generic +slug: /protocol/generic +id: protocol-generic title: Generic Message Passing description: The following details how Generic message passing is handled by Sygma. --- diff --git a/docs/01-introduction/04-Governance/01-governance.md b/docs/02-sygma-protocol/08-Governance/01-governance.md similarity index 95% rename from docs/01-introduction/04-Governance/01-governance.md rename to docs/02-sygma-protocol/08-Governance/01-governance.md index 1f590ae..ff38e31 100644 --- a/docs/01-introduction/04-Governance/01-governance.md +++ b/docs/02-sygma-protocol/08-Governance/01-governance.md @@ -19,4 +19,4 @@ See [Cryptonetwork Governance As Capital](https://www.placeholder.vc/blog/2019/2 ### Relayer Network Administration -Becoming a relayer in the Sygma network is currently a permissioned process. You can find more information around the current relaying partners as well as how to become a partner in [Becoming A Relayer Partner](../../04-ecosystem/03-relayer-partner.md). \ No newline at end of file +Becoming a relayer in the Sygma network is currently a permissioned process. You can find more information around the current relaying partners as well as how to become a partner in [Becoming A Relayer Partner](../../04-integrating-with-sygma/05-relayer-partner.md). \ No newline at end of file diff --git a/docs/01-introduction/04-Governance/02-evm-multisigs.md b/docs/02-sygma-protocol/08-Governance/02-evm-multisigs.md similarity index 100% rename from docs/01-introduction/04-Governance/02-evm-multisigs.md rename to docs/02-sygma-protocol/08-Governance/02-evm-multisigs.md diff --git a/docs/01-introduction/04-Governance/03-substrate-multisig.md b/docs/02-sygma-protocol/08-Governance/03-substrate-multisig.md similarity index 100% rename from docs/01-introduction/04-Governance/03-substrate-multisig.md rename to docs/02-sygma-protocol/08-Governance/03-substrate-multisig.md diff --git a/docs/01-introduction/04-Governance/04-future-state.md b/docs/02-sygma-protocol/08-Governance/04-future-state.md similarity index 100% rename from docs/01-introduction/04-Governance/04-future-state.md rename to docs/02-sygma-protocol/08-Governance/04-future-state.md diff --git a/docs/02-sygma-protocol/_category_.json b/docs/02-sygma-protocol/_category_.json new file mode 100644 index 0000000..cfb05bc --- /dev/null +++ b/docs/02-sygma-protocol/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "Sygma Protocol", + "position": 2, + "link": { + "type": "doc", + "id": "protocol-index" + } +} diff --git a/docs/02-sygma-sdk/03-Quick-Start/05-sygma-widget.md b/docs/02-sygma-sdk/03-Quick-Start/05-sygma-widget.md deleted file mode 100644 index 2ac239c..0000000 --- a/docs/02-sygma-sdk/03-Quick-Start/05-sygma-widget.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -slug: /sdk/quickstart/widget -id: quickstart-widget -title: Using The Sygma UI Widget -description: The following section details how to use the Sygma UI widget. -sidebar_position: 5 -draft: true ---- - -More to come soon... \ No newline at end of file diff --git a/docs/02-sygma-sdk/_category_.json b/docs/02-sygma-sdk/_category_.json deleted file mode 100644 index 55de667..0000000 --- a/docs/02-sygma-sdk/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Sygma SDK", - "position": 2, - "link": { - "type": "doc", - "id": "sdk-index" - } - } \ No newline at end of file diff --git a/docs/03-architecture/01-index.md b/docs/03-architecture/01-index.md deleted file mode 100644 index 0dc2dc0..0000000 --- a/docs/03-architecture/01-index.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -slug: /architecture -id: architecture-index -title: Architecture -description: The following details the architecture of Sygma. ---- - -:::info -The following details the architecture of Sygma. -::: - -The Sygma messaging protocol is able to transfer arbitrary data. This allows us to transfer not only ERC-20 tokens, but also ERC-721 (e.g. NFTs), in addition to something else we refer to as: **Generic data.** 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). - -Currently, the Sygma protocol is compatible with EVM and Substrate-based networks, but is proven to be easily extended to other networks such as Cosmos-based chains (Tendermint) as well. - -Sygma Bridging Flow Diagram - -![](<../../static/assets/Bridging Diagram.png>) diff --git a/docs/03-architecture/02-mpc.md b/docs/03-architecture/02-mpc.md deleted file mode 100644 index 0939128..0000000 --- a/docs/03-architecture/02-mpc.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -slug: /architecture/mpc -id: architecture-mpc -title: MPC -description: The following details how MPC is utilized by Sygma. ---- - -:::info -The following details how MPC is utilized by Sygma. -::: - -**Secure 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](/docs/03-architecture/04-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. - -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 more on how MPC is used by Sygma, see [Security](/docs/03-architecture/05-security/01-Security-Intro.md). - -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. diff --git a/docs/03-architecture/04-relayers.md b/docs/03-architecture/04-relayers.md deleted file mode 100644 index 4a59808..0000000 --- a/docs/03-architecture/04-relayers.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -slug: /architecture/relayers -id: architecture-relayers -title: Relayers -description: The following details how relayers are defined and managed by Sygma. ---- - -:::info -The following details how relayers are defined and managed by Sygma. -::: - -_Relayers are entities that ensure bridge decentralization and execute asset bridging._ - -At the core of Sygma exists a **set of relayers** that are distributed among several legal entities and operate under a trusted federation model. Spreading the relayer set across several legal entities creates a distribution of responsibilities and mitigates risk by disincentivizing relayers in the set to act in an unfair manner. - -Each relayer within the set listens to both the source and destination chains that are being bridged by Sygma. Based on events that are emitted, these relayers then execute relevant actions. - -This multi-relayer set is responsible for relaying messages from a source network to a destination network. Relayers are operating with private key share and execution happens on the destination network with [MPC](/docs/03-architecture/02-mpc.md) private key. - -Communication between relayer parties happens in a [p2p](https://en.wikipedia.org/wiki/Peer-to-peer) manner; and participants of [p2p](https://en.wikipedia.org/wiki/Peer-to-peer) and MPC communication are strictly defined by a configuration file this allows us to prevent [Sybil Attacks](https://en.wikipedia.org/wiki/Sybil\_attack). - -For more on our current list of relayer partners or learn how to become one, please see [Becoming A Relayer Partner](/docs/04-ecosystem/03-relayer-partner.md). diff --git a/docs/03-architecture/05-security/_category_.json b/docs/03-architecture/05-security/_category_.json deleted file mode 100644 index 0eebd04..0000000 --- a/docs/03-architecture/05-security/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Security", - "position": 1 -} diff --git a/docs/03-architecture/_category_.json b/docs/03-architecture/_category_.json deleted file mode 100644 index 434493b..0000000 --- a/docs/03-architecture/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Architecture", - "position": 3, - "link": { - "type": "doc", - "id": "architecture-index" - } -} diff --git a/docs/02-sygma-sdk/01-index.md b/docs/03-sygma-sdk/01-index.md similarity index 92% rename from docs/02-sygma-sdk/01-index.md rename to docs/03-sygma-sdk/01-index.md index 84dd696..08877a9 100644 --- a/docs/02-sygma-sdk/01-index.md +++ b/docs/03-sygma-sdk/01-index.md @@ -1,13 +1,11 @@ --- slug: /sdk -id: sdk-index -title: Introduction +id: sdk +title: Introduction To The Sygma SDK description: The following section introduces the Sygma SDK. sidebar_position: 1 --- -## Introduction - **Sygma SDK** is an open source library (under [GNU Lesser General Public License v3.0](https://www.gnu.org/licenses/lgpl-3.0.en.html)) for developers to work within the Sygma ecosystem. The SDK consist of methods that enable bridging capabilities between EVM and Substrate-based networks. **NOTE:** the SDK is under active development. We encourage developers that discover any bugs or are interested in extending SDK functionality to [submit issues](https://github.com/sygmaprotocol/sygma-sdk/issues) to our GitHub. \ No newline at end of file diff --git a/docs/02-sygma-sdk/03-Quick-Start/01-installing-the-sdk.md b/docs/03-sygma-sdk/02-Quick-Start/01-installing-the-sdk.md similarity index 100% rename from docs/02-sygma-sdk/03-Quick-Start/01-installing-the-sdk.md rename to docs/03-sygma-sdk/02-Quick-Start/01-installing-the-sdk.md diff --git a/docs/02-sygma-sdk/03-Quick-Start/02-evm-token-tranfers.md b/docs/03-sygma-sdk/02-Quick-Start/02-evm-token-tranfers.md similarity index 100% rename from docs/02-sygma-sdk/03-Quick-Start/02-evm-token-tranfers.md rename to docs/03-sygma-sdk/02-Quick-Start/02-evm-token-tranfers.md diff --git a/docs/02-sygma-sdk/03-Quick-Start/03-substrate-token-transfer.md b/docs/03-sygma-sdk/02-Quick-Start/03-substrate-token-transfer.md similarity index 100% rename from docs/02-sygma-sdk/03-Quick-Start/03-substrate-token-transfer.md rename to docs/03-sygma-sdk/02-Quick-Start/03-substrate-token-transfer.md diff --git a/docs/02-sygma-sdk/03-Quick-Start/04-gmp.md b/docs/03-sygma-sdk/02-Quick-Start/04-gmp.md similarity index 94% rename from docs/02-sygma-sdk/03-Quick-Start/04-gmp.md rename to docs/03-sygma-sdk/02-Quick-Start/04-gmp.md index cf4293e..36743f1 100644 --- a/docs/02-sygma-sdk/03-Quick-Start/04-gmp.md +++ b/docs/03-sygma-sdk/02-Quick-Start/04-gmp.md @@ -21,9 +21,9 @@ To facilitate the transfer, the following steps are required: 2. Determine the fee for the transfer, using the `EVMGenericMessageTransfer.getFee()` method 3. Prepare, sign, and send the Transfer transaction to the Source network node -The `executeDeposit` function prepares and populates a deposit transaction. The key parameter is `depositData`, which is a string requiring a specific format. Refer to the [Generic Message Passing](../../03-architecture/06-generic.md) documentation for instructions on how to format the `depositData` string correctly. +The `executeDeposit` function prepares and populates a deposit transaction. The key parameter is `depositData`, which is a string requiring a specific format. Refer to the [Generic Message Passing](../../02-sygma-protocol/06-generic.md) documentation for instructions on how to format the `depositData` string correctly. -There are a few requirements for the Destination chain contract function that gets called. Refer to the [Generic Message Passing](../../03-architecture/06-generic.md) documentation for details. +There are a few requirements for the Destination chain contract function that gets called. Refer to the [Generic Message Passing](../../02-sygma-protocol/06-generic.md) documentation for details. #### 1. Initialize the EvmAssetTransfer object diff --git a/docs/02-sygma-sdk/03-Quick-Start/06-txstatus.md b/docs/03-sygma-sdk/02-Quick-Start/05-txstatus.md similarity index 95% rename from docs/02-sygma-sdk/03-Quick-Start/06-txstatus.md rename to docs/03-sygma-sdk/02-Quick-Start/05-txstatus.md index db45722..d967a37 100644 --- a/docs/02-sygma-sdk/03-Quick-Start/06-txstatus.md +++ b/docs/03-sygma-sdk/02-Quick-Start/05-txstatus.md @@ -9,7 +9,7 @@ draft: false ### Using the Sygma Explorer -You can easily check the status of a cross-chain transfer invoked through the Sygma SDK using the [Sygma Explorer](../../04-ecosystem/04-explorer.md) UI. +You can easily check the status of a cross-chain transfer invoked through the Sygma SDK using the [Sygma Explorer](../../04-integrating-with-sygma/02-explorer.md) UI. ### Using the `getTransferStatusData` function diff --git a/docs/02-sygma-sdk/04-Advanced/01-local-setup.md b/docs/03-sygma-sdk/03-Advanced/01-local-setup.md similarity index 100% rename from docs/02-sygma-sdk/04-Advanced/01-local-setup.md rename to docs/03-sygma-sdk/03-Advanced/01-local-setup.md diff --git a/docs/02-sygma-sdk/04-Advanced/02-create-own-handler.md b/docs/03-sygma-sdk/03-Advanced/02-create-own-handler.md similarity index 100% rename from docs/02-sygma-sdk/04-Advanced/02-create-own-handler.md rename to docs/03-sygma-sdk/03-Advanced/02-create-own-handler.md diff --git a/docs/02-sygma-sdk/04-Advanced/03-custom-fees.md b/docs/03-sygma-sdk/03-Advanced/03-custom-fees.md similarity index 100% rename from docs/02-sygma-sdk/04-Advanced/03-custom-fees.md rename to docs/03-sygma-sdk/03-Advanced/03-custom-fees.md diff --git a/docs/02-sygma-sdk/03-Quick-Start/07-Examples/01-Basic-ERC-20-Token-Transfers/01-EVM-EVM-example.md b/docs/03-sygma-sdk/04-Examples/01-Basic-ERC-20-Token-Transfers/01-EVM-EVM-example.md similarity index 81% rename from docs/02-sygma-sdk/03-Quick-Start/07-Examples/01-Basic-ERC-20-Token-Transfers/01-EVM-EVM-example.md rename to docs/03-sygma-sdk/04-Examples/01-Basic-ERC-20-Token-Transfers/01-EVM-EVM-example.md index d040892..ed237dd 100644 --- a/docs/02-sygma-sdk/03-Quick-Start/07-Examples/01-Basic-ERC-20-Token-Transfers/01-EVM-EVM-example.md +++ b/docs/03-sygma-sdk/04-Examples/01-Basic-ERC-20-Token-Transfers/01-EVM-EVM-example.md @@ -1,5 +1,5 @@ --- -slug: /sdk/quickstart/examples/erc20/evm-example +slug: /sdk/examples/erc20/evm-example id: examples-erc20-evm-example title: EVM To EVM Token Transfer description: Section that describes how to perform an EVM to EVM token transfer. @@ -9,7 +9,7 @@ draft: false ### EVM-to-EVM token transfer example -In the following example, we will use the `TESTNET` environment to perform a cross-chain ERC-20 transfer with 5 `ERC20LRTST` tokens. The transfer will be initiated on the EVM-side via the Mumbai testnet and received on the EVM-side via the Sepolia Ethereum testnet. +In the following example, we will use the `TESTNET` environment to perform a cross-chain ERC-20 transfer with 5 `ERC20LRTST` tokens. The transfer will be initiated on the EVM-side via the Cronos testnet and received on the EVM-side via the Sepolia Ethereum testnet. This is an example script that demonstrates the functionality of the Sygma SDK and the wider Sygma ecosystem of relayers and bridge and handler contracts. The complete example can be found in this [repo]( https://github.com/sygmaprotocol/sygma-sdk/tree/main/examples/evm-to-evm-fungible-transfer). @@ -21,11 +21,11 @@ Before running the script, ensure that you have the following: - Node.js v18 - Yarn (version 3.4.1 or higher) - The [exported private key](https://support.metamask.io/hc/en-us/articles/360015289632-How-to-export-an-account-s-private-key) of your development wallet -- [Mumbai](https://mumbaifaucet.com/) for gas +- Testnet [CRO](https://docs.cronos.org/for-users/testnet-faucet) for gas - An Ethereum [provider](https://www.infura.io/) (in case the hardcoded RPC within the script does not work) - A development wallet funded with `ERC20LRTest` tokens from the [Sygma faucet](https://faucet-ui-stage.buildwithsygma.com/) (you can use the UI below; please allow some time for minting as testnet may be congested) -import App from '../../../../../src/Faucet/App'; +import App from '../../../../src/Faucet/App';
@@ -85,7 +85,7 @@ cd examples/evm-to-evm-fungible-transfer yarn run transfer ``` -The example will use `ethers` in conjunction with the sygma-sdk to create a transfer from Mumbai to Sepolia with the `ERC20LRTST` token. It will be received on Sepolia as the `ERC20LRTST` token. +The example will use `ethers` in conjunction with the sygma-sdk to create a transfer from Cronos to Sepolia with the `ERC20LRTST` token. It will be received on Sepolia as the `ERC20LRTST` token. ### Script functionality @@ -94,12 +94,19 @@ This example script performs the following steps: - Initializes the SDK by importing the required packages and defining the constants for the script. ```ts -import { EVMAssetTransfer, Environment, getTransferStatusData } from "@buildwithsygma/sygma-sdk-core"; +import { EVMAssetTransfer, Environment, getTransferStatusData, TransferStatusResponse } from "@buildwithsygma/sygma-sdk-core"; import { Wallet, providers } from "ethers"; const SEPOLIA_CHAIN_ID = 11155111; const RESOURCE_ID = "0x0000000000000000000000000000000000000000000000000000000000000300"; // This is the resource ID for the ERC20LRTEST token according to Sygma's testnet environment +const CRONOS_RPC_URL = process.env.CRONOS_RPC_URL || "https://evm-t3.cronos.org" // use your own provider in case this RPC URL does not work +const getStatus = async ( + txHash: string +): Promise => { + const data = await getTransferStatusData(Environment.TESTNET, txHash); + return data as TransferStatusResponse[]; +}; ``` - Configures the dotenv module and sets the `privateKey` as a value to be pulled from the `.env` file. @@ -121,16 +128,12 @@ if (!privateKey) { ```ts export async function erc20Transfer(): Promise { ``` + - Set up the provider, wallet, and asset transfer objects using the TESTNET environment. ```ts - const provider = new providers.JsonRpcProvider( - "https://polygon-mumbai-pokt.nodies.app" // use your own provider in case this does not work - ); - const wallet = new Wallet( - privateKey as string, - provider - ); + const provider = new providers.JsonRpcProvider(CRONOS_RPC_URL); + const wallet = new Wallet(privateKey ?? "", provider); const assetTransfer = new EVMAssetTransfer(); await assetTransfer.init(provider, Environment.TESTNET); ``` @@ -151,49 +154,34 @@ export async function erc20Transfer(): Promise { - Builds the necessary approval transactions for the transfer and sends them using the Ethereum wallet. The approval transactions are required to authorize the transfer of ERC-20 tokens. ```ts - const fee = await assetTransfer.getFee(transfer); +const fee = await assetTransfer.getFee(transfer); const approvals = await assetTransfer.buildApprovals(transfer, fee); for (const approval of approvals) { const response = await wallet.sendTransaction( approval as providers.TransactionRequest ); console.log("Sent approval with hash: ", response.hash); - } ``` + - Invokes the `getTransferStatusData` and `getStatus` functions by taking the transaction hash as an input to periodically check the status of the cross-chain transaction. ```ts -const getStatus = async ( - txHash: string -): Promise<{ status: string; explorerUrl: string } | void> => { - try { - const data = await getTransferStatusData(Environment.TESTNET, txHash); - return data as { status: string; explorerUrl: string }; - } catch (e) { - console.log("error:", e); - } -}; - - let dataResponse: undefined | { status: string; explorerUrl: string }; - - const id = setInterval(() => { +const id = setInterval(() => { getStatus(response.hash) .then((data) => { - if (data) { - dataResponse = data; - console.log("Status of the transfer", data.status); + if (data[0]) { + console.log("Status of the transfer", data[0].status); + if(data[0].status == "executed") { + clearInterval(id); + process.exit(0); + } + } else { + console.log("Waiting for the TX to be indexed"); } }) .catch((e) => { console.log("error:", e); - console.log("Transfer still not indexed, retrying..."); }); - - if (dataResponse && dataResponse.status === "executed") { - console.log("Transfer executed successfully"); - clearInterval(id); - process.exit(0); - } }, 5000); } ``` diff --git a/docs/02-sygma-sdk/03-Quick-Start/07-Examples/01-Basic-ERC-20-Token-Transfers/02-EVM-Substrate-example.md b/docs/03-sygma-sdk/04-Examples/01-Basic-ERC-20-Token-Transfers/02-EVM-Substrate-example.md similarity index 83% rename from docs/02-sygma-sdk/03-Quick-Start/07-Examples/01-Basic-ERC-20-Token-Transfers/02-EVM-Substrate-example.md rename to docs/03-sygma-sdk/04-Examples/01-Basic-ERC-20-Token-Transfers/02-EVM-Substrate-example.md index ce4fab4..d787fb2 100644 --- a/docs/02-sygma-sdk/03-Quick-Start/07-Examples/01-Basic-ERC-20-Token-Transfers/02-EVM-Substrate-example.md +++ b/docs/03-sygma-sdk/04-Examples/01-Basic-ERC-20-Token-Transfers/02-EVM-Substrate-example.md @@ -1,5 +1,5 @@ --- -slug: /sdk/quickstart/examples/erc20/evm-substrate-example +slug: /sdk/examples/erc20/evm-substrate-example id: examples-erc20-evm-substrate-example title: EVM To Substrate Token Transfer description: Section that describes how to perform an EVM to Substrate token transfer. @@ -26,7 +26,7 @@ Before running the script, ensure that you have the following: - An Ethereum [provider](https://www.infura.io/) (in case the hardcoded RPC within the script does not work) - A development wallet funded with `sygUSD` tokens from the [Sygma faucet](https://faucet-ui-stage.buildwithsygma.com/) -import App from '../../../../../src/Faucet/App'; +import App from '../../../../src/Faucet/App';
@@ -97,13 +97,20 @@ This example script performs the following steps: - Initializes the SDK by importing the required packages and defining the constants for the script. ```ts -import { EVMAssetTransfer, Environment, getTransferStatusData } from "@buildwithsygma/sygma-sdk-core"; +import { EVMAssetTransfer, Environment, getTransferStatusData, TransferStatusResponse } from "@buildwithsygma/sygma-sdk-core"; import { Wallet, providers } from "ethers"; const ROCOCO_PHALA_CHAIN_ID = 5231; -const DESTINATION_ADDRESS = "5CDQJk6kxvBcjauhrogUc9B8vhbdXhRscp1tGEUmniryF1Vt"; // replace this value for your preferred Substrate address +const DESTINATION_ADDRESS = "5CDQJk6kxvBcjauhrogUc9B8vhbdXhRscp1tGEUmniryF1Vt"; const RESOURCE_ID = - "0x0000000000000000000000000000000000000000000000000000000000001100"; // This is the resource ID for the sygUSD token according to Sygma's testnet environment + "0x0000000000000000000000000000000000000000000000000000000000001100"; +const SEPOLIA_RPC_URL = process.env.SEPOLIA_RPC_URL || "https://gateway.tenderly.co/public/sepolia" // use your another RPC URL in case this does not work +const getStatus = async ( + txHash: string +): Promise => { + const data = await getTransferStatusData(Environment.TESTNET, txHash); + return data as TransferStatusResponse[]; +}; ``` - Configures the dotenv module and sets the `privateKey` as a value to be pulled from the `.env` file. @@ -128,13 +135,9 @@ export async function erc20Transfer(): Promise { - Set up the provider, wallet, and asset transfer objects using the TESTNET environment. ```ts - const provider = new providers.JsonRpcProvider( - "https://rpc.sepolia.eth.gateway.fm/" // use your own provider in case this does not work - ); - const wallet = new Wallet( - privateKey as string, - provider - ); +export async function erc20Transfer(): Promise { + const provider = new providers.JsonRpcProvider(SEPOLIA_RPC_URL); + const wallet = new Wallet(privateKey ?? "", provider); const assetTransfer = new EVMAssetTransfer(); await assetTransfer.init(provider, Environment.TESTNET); ``` @@ -167,37 +170,22 @@ export async function erc20Transfer(): Promise { - Invokes the `getTransferStatusData` and `getStatus` functions by taking the transaction hash as an input to periodically check the status of the cross-chain transaction. ```ts -const getStatus = async ( - txHash: string -): Promise<{ status: string; explorerUrl: string } | void> => { - try { - const data = await getTransferStatusData(Environment.TESTNET, txHash); - - return data as { status: string; explorerUrl: string }; - } catch (e) { - console.log("error: ", e); - } -}; - - let dataResponse: undefined | { status: string; explorerUrl: string }; - const id = setInterval(() => { getStatus(response.hash) .then((data) => { - if (data) { - dataResponse = data; - console.log(data); + if (data[0]) { + console.log("Status of the transfer", data[0].status); + if(data[0].status == "executed") { + clearInterval(id); + process.exit(0); + } + } else { + console.log("Waiting for the TX to be indexed"); } }) - .catch(() => { - console.log("Transfer still not indexed, retrying..."); + .catch((e) => { + console.log("error:", e); }); - - if (dataResponse && dataResponse.status === "executed") { - console.log("Transfer executed successfully"); - clearInterval(id); - process.exit(0); - } }, 5000); } ``` @@ -205,7 +193,7 @@ const getStatus = async ( - Builds the final `transfer` transaction and sends it using the Ethereum wallet. ```ts - const transferTx = await assetTransfer.buildTransferTransaction( + const transferTx = await assetTransfer.buildTransferTransaction( transfer, fee ); diff --git a/docs/02-sygma-sdk/03-Quick-Start/07-Examples/01-Basic-ERC-20-Token-Transfers/03-Substrate-EVM-example.md b/docs/03-sygma-sdk/04-Examples/01-Basic-ERC-20-Token-Transfers/03-Substrate-EVM-example.md similarity index 77% rename from docs/02-sygma-sdk/03-Quick-Start/07-Examples/01-Basic-ERC-20-Token-Transfers/03-Substrate-EVM-example.md rename to docs/03-sygma-sdk/04-Examples/01-Basic-ERC-20-Token-Transfers/03-Substrate-EVM-example.md index 2b30294..6dd62ac 100644 --- a/docs/02-sygma-sdk/03-Quick-Start/07-Examples/01-Basic-ERC-20-Token-Transfers/03-Substrate-EVM-example.md +++ b/docs/03-sygma-sdk/04-Examples/01-Basic-ERC-20-Token-Transfers/03-Substrate-EVM-example.md @@ -1,5 +1,5 @@ --- -slug: /sdk/quickstart/examples/erc20/substrate-evm-example +slug: /sdk/examples/erc20/substrate-evm-example id: examples-erc20-substrate-evm-example title: Substrate To EVM Token Transfer description: Section that describes how to perform a Substrate to EVM token transfer. @@ -93,12 +93,25 @@ This example script performs the following steps: import { Keyring } from "@polkadot/keyring"; import { ApiPromise, WsProvider } from "@polkadot/api"; import { cryptoWaitReady } from "@polkadot/util-crypto"; -import { Environment, Substrate, getTransferStatusData } from "@buildwithsygma/sygma-sdk-core"; +import dotenv from "dotenv"; +import { + Environment, + Substrate, + getTransferStatusData, + TransferStatusResponse +} from "@buildwithsygma/sygma-sdk-core"; const { SubstrateAssetTransfer } = Substrate; + const SEPOLIA_CHAIN_ID = 11155111; -const RESOURCE_ID = "0x0000000000000000000000000000000000000000000000000000000000001100"; // This is the resource ID for the sygUSD token according to Sygma's testnet environment -const recipient = "0xD31E89feccCf6f2DE10EaC92ADffF48D802b695C"; // replace this value for your preferred EVM address +const RESOURCE_ID = + "0x0000000000000000000000000000000000000000000000000000000000001100"; // this is the resourceID for sygUSD +const MNEMONIC = process.env.PRIVATE_MNEMONIC; +const recipient = "0xD31E89feccCf6f2DE10EaC92ADffF48D802b695C"; // replace this value for your preferred EVM recipient address +const RHALA_RPC_URL = process.env.RHALA_RPC_URL || "wss://rhala-node.phala.network/ws" +if (!MNEMONIC) { + throw new Error("Missing environment variable: PRIVATE_MNEMONIC"); +} ``` - Configures the dotenv module and sets the `MNEMONIC` as a value to be pulled from the `.env` file. @@ -120,51 +133,41 @@ if (!MNEMONIC) { ```ts const substrateTransfer = async (): Promise => { const keyring = new Keyring({ type: "sr25519" }); + // Make sure to fund this account with native tokens + // Account address: 5FNHV5TZAQ1AofSPbP7agn5UesXSYDX9JycUSCJpNuwgoYTS + await cryptoWaitReady(); - const account = keyring.addFromUri(MNEMONIC as string); - const wsProvider = new WsProvider("wss://subbridge-test.phala.network/rhala/ws"); + + const account = keyring.addFromUri(MNEMONIC); + + const wsProvider = new WsProvider(RHALA_RPC_URL); const api = await ApiPromise.create({ provider: wsProvider }); + const assetTransfer = new SubstrateAssetTransfer(); + await assetTransfer.init(api, Environment.TESTNET); - ... -} ``` - Invokes the `getTransferStatusData` and `getStatus` functions by taking the transaction hash as an input to periodically check the status of the cross-chain transaction. ```ts -const getStatus = async ( - txHash: string -): Promise<{ status: string; explorerUrl: string } | void> => { - try { - const data = await getTransferStatusData(Environment.TESTNET, txHash); - - return data as { status: string; explorerUrl: string }; - } catch (e) { - console.log("error: ", e); - } -}; - - let dataResponse: undefined | { status: string; explorerUrl: string }; - - const id = setInterval(() => { +const id = setInterval(() => { getStatus(status.asInBlock.toString()) .then((data) => { - if (data) { - dataResponse = data; - console.log(data); + if (data[0]) { + console.log("Status of the transfer", data[0].status); + if(data[0].status == "executed") { + clearInterval(id); + process.exit(0); + } + } else { + console.log("Waiting for the TX to be indexed"); } }) - .catch(() => { - console.log("Transfer still not indexed, retrying..."); + .catch((e) => { + console.log("error:", e); }); }, 5000); - - if (dataResponse && dataResponse.status === "executed") { - console.log("Transfer executed successfully"); - clearInterval(id); - process.exit(0); - } }); }; ``` @@ -172,18 +175,21 @@ const getStatus = async ( - Constructs a transfer object that calculates the fee, then builds, signs, and sends the transaction. ```ts -const transfer = assetTransfer.createFungibleTransfer( - account.address, - SEPOLIA_CHAIN_ID, - recipient, - RESOURCE_ID, - "500000000000000000" // 18 decimal places, so in this case 0.5 sygUSD tokens -); -const fee = await assetTransfer.getFee(transfer); const transferTx = assetTransfer.buildTransferTransaction(transfer, fee); -const unsub = await transferTx.signAndSend(account, ({ status }) => { - ... -}); + + const unsub = await transferTx.signAndSend(account, ({ status }) => { + console.log(`Current status is ${status.toString()}`); + + if (status.isInBlock) { + console.log( + `Transaction included at blockHash ${status.asInBlock.toString()}` + ); + } else if (status.isFinalized) { + console.log( + `Transaction finalized at blockHash ${status.asFinalized.toString()}` + ); + unsub(); + } ``` - Logs the current status of the transaction, and if it's included in a block or finalized, outputs the respective block hash. diff --git a/docs/02-sygma-sdk/03-Quick-Start/07-Examples/02-GMP-Examples/04-GMP-Example-With-A-Simple-Storage-Contract.md b/docs/03-sygma-sdk/04-Examples/02-GMP-Examples/01-GMP-Example-With-A-Simple-Storage-Contract.md similarity index 82% rename from docs/02-sygma-sdk/03-Quick-Start/07-Examples/02-GMP-Examples/04-GMP-Example-With-A-Simple-Storage-Contract.md rename to docs/03-sygma-sdk/04-Examples/02-GMP-Examples/01-GMP-Example-With-A-Simple-Storage-Contract.md index 938290f..e523b3a 100644 --- a/docs/02-sygma-sdk/03-Quick-Start/07-Examples/02-GMP-Examples/04-GMP-Example-With-A-Simple-Storage-Contract.md +++ b/docs/03-sygma-sdk/04-Examples/02-GMP-Examples/01-GMP-Example-With-A-Simple-Storage-Contract.md @@ -9,7 +9,7 @@ draft: false ### GMP Example With A Simple Storage Contract -In the following example, we will use the `TESTNET` environment to pass a generic message from Ethereum Sepolia to Polygon Mumbai using a simple storage contract. Specifically, the `deposit` method will be called on Sepolia, passing the details of the function to be called (the `store` function, or function signature `0xa271ced2`) on a smart contract deployed on Sepolia "[0x6f250a12f9a2d6f72b6e8ef5b93484da04cdb69e](https://mumbai.polygonscan.com/address/0x6f250a12f9a2d6f72b6e8ef5b93484da04cdb69e)". The method will encode the current UNIX timestamp as the payload to be passed and stored in the destination chain contract. The data can be read by calling the `retrieve` function on the destination chain contract by querying the depositor address derived from the private key. +In the following example, we will use the `TESTNET` environment to pass a generic message from Ethereum Sepolia to Cronos Testnet using a simple storage contract. Specifically, the `deposit` method will be called on Sepolia, passing the details of the function to be called (the `store` function, or function signature `0xa271ced2`) on a smart contract deployed on Cronos ([0xcb9eb2b2abbd51945a82f77e789c26720b3835bf](https://explorer.cronos.org/testnet/address/0xcb9eb2b2abbd51945a82f77e789c26720b3835bf)). The method will encode the current UNIX timestamp as the payload to be passed and stored in the destination chain contract. The data can be read by calling the `retrieve` function on the destination chain contract by querying the depositor address derived from the private key. This is an example script that demonstrates the functionality of the Sygma SDK and the wider Sygma ecosystem of relayers and bridge and handler contracts. The complete example can be found in this [repo]( https://github.com/sygmaprotocol/sygma-sdk/tree/main/examples/evm-to-evm-generic-mesage-passing). @@ -79,7 +79,7 @@ cd examples/evm-to-evm-generic-mesage-passing yarn run transfer ``` -The example will use `ethers` in conjunction with the sygma-sdk to call a function on a smart contract on Mumbai by calling the `Deposit` method on Sepolia and passing the details of the function to be called. +The example will use `ethers` in conjunction with the sygma-sdk to call a function on a smart contract on Cronos by calling the `Deposit` method on Sepolia and passing the details of the function to be called. Replace the placeholder values in the `.env` file with your own Ethereum wallet private key and provider URL. diff --git a/docs/02-sygma-sdk/03-Quick-Start/07-Examples/05-NodeJS-Token-Transfer-Example.md b/docs/03-sygma-sdk/04-Examples/05-NodeJS-Token-Transfer-Example.md similarity index 100% rename from docs/02-sygma-sdk/03-Quick-Start/07-Examples/05-NodeJS-Token-Transfer-Example.md rename to docs/03-sygma-sdk/04-Examples/05-NodeJS-Token-Transfer-Example.md diff --git a/docs/03-sygma-sdk/_category_.json b/docs/03-sygma-sdk/_category_.json new file mode 100644 index 0000000..8a6258e --- /dev/null +++ b/docs/03-sygma-sdk/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Building A DApp With Sygma", + "position": 3 + } \ No newline at end of file diff --git a/docs/04-ecosystem/_category_.json b/docs/04-ecosystem/_category_.json deleted file mode 100644 index e65f80a..0000000 --- a/docs/04-ecosystem/_category_.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "label": "Ecosystem", - "position": 4 - - } - \ No newline at end of file diff --git a/docs/04-integrating-with-sygma/01-Sygma Widget/01-index.md b/docs/04-integrating-with-sygma/01-Sygma Widget/01-index.md new file mode 100644 index 0000000..9ebff4c --- /dev/null +++ b/docs/04-integrating-with-sygma/01-Sygma Widget/01-index.md @@ -0,0 +1,65 @@ +--- +id: sygma-widget-index +slug: /sygma-widget +title: Introduction To The Sygma Widget +description: The following section provides details on the Sygma Widget. +sidebar_position: 1 +--- + +The Sygma protocol provides an open source, customizable frontend UI, the **Sygma Widget**, to make integration of the Sygma interoperability protocol easier. + +The source code can be found in the [sygma-widget repo](https://github.com/sygmaprotocol/sygma-widget). + +The repository is organized into two packages and one example: +- The [Widget](https://github.com/sygmaprotocol/sygma-widget/tree/main/packages/widget) package is a web component built using the Lit framework. +- The [React](https://github.com/sygmaprotocol/sygma-widget/tree/main/packages/react) package is a wrapper around the Lit widget that allows developers to use this application inside React projects. +- The [examples/react-widget-app] package is an example of a stylized React widget. + +## Quick Setup + +1. Create a Vite template project called `my-dapp`: + +```bash +yarn create vite my-dapp --template react-ts +cd ./my-dapp +touch yarn.lock +``` + +2. Install dependencies: + +```bash +yarn install +yarn add @buildwithsygma/sygmaprotocol-react-widget @buildwithsygma/sygma-sdk-core +``` + +3. Boot up the local server: + +```bash +yarn dev +``` + +## How To Integrate + +Follow the [Lit](02-lit.md) or [React](03-react.md) documentation for framework-specific instructions. + +## Widget Properties + +The behaviour of the Sygma Widget can be customized using configurable properties (props). A complete reference of the properties can be found under [packages/widget/src/widget.ts](https://github.com/sygmaprotocol/sygma-widget/blob/main/packages/widget/src/widget.ts)/ + +Below you will find an example of props being passed to whitelist (i.e enable) the source and destination networks in the React component: + +```ts +// App.tsx +import { SygmaProtocolReactWidget } from "@buildwithsygma/sygmaprotocol-react-widget"; + +function MyDapp() { + const [count, setCount] = useState(0); + + return ( + + ); +} +``` \ No newline at end of file diff --git a/docs/04-integrating-with-sygma/01-Sygma Widget/02-lit.md b/docs/04-integrating-with-sygma/01-Sygma Widget/02-lit.md new file mode 100644 index 0000000..0df9813 --- /dev/null +++ b/docs/04-integrating-with-sygma/01-Sygma Widget/02-lit.md @@ -0,0 +1,61 @@ +--- +id: sygma-widget-lit +slug: /sygma-widget/lit +title: Lit Framework +description: The following section provides details on the Sygma Lit Widget. +sidebar_position: 2 +--- + +## Dependencies + +Add the following dependencies to integrate the widget into any Lit project: + +```bash +yarn add @buildwithsygma/sygmaprotocol-widget @buildwithsygma/sygma-sdk-core +``` + +## Integrating The Widget Into Your Lit Code + +Import the `sygmaprotocol-widget` dependency to add the widget to your existing codebase. Add the custom tag into your render method: + +```ts +import { LitElement, html } from 'lit' +import { customElement, property } from 'lit/decorators.js' +import '@buildwithsygma/sygmaprotocol-widget' + +@customElement('my-element') +export class MyElement extends LitElement { + render() { + return html` +
+ +
+ ` + } + +} + +declare global { + interface HTMLElementTagNameMap { + 'my-element': MyElement + } +} +``` + +You can also pass properties into the widget to customize its behaviour: + +```ts +render() { + return html` +
+ +
+ ` + } +``` + +See [widget.ts](https://github.com/sygmaprotocol/sygma-widget/blob/main/packages/widget/src/widget.ts) for all of the available properties. \ No newline at end of file diff --git a/docs/04-integrating-with-sygma/01-Sygma Widget/03-react.md b/docs/04-integrating-with-sygma/01-Sygma Widget/03-react.md new file mode 100644 index 0000000..d30b885 --- /dev/null +++ b/docs/04-integrating-with-sygma/01-Sygma Widget/03-react.md @@ -0,0 +1,52 @@ +--- +id: sygma-widget-react +slug: /sygma-widget/react +title: React Framework +description: The following section provides details on the Sygma React Widget. +sidebar_position: 3 +--- + +## Dependencies + +Add the following dependencies to integrate the widget into any React project: + +```bash +yarn add @polkadot/extension-inject +``` + +And similarly: + +```bash +yarn add @buildwithsygma/sygmaprotocol-react-widget @buildwithsygma/sygma-sdk-core +``` + +### Integrating The Widget Into Your React Code + +After installation, add the widget into your code using: + +```ts +import { SygmaProtocolReactWidget } from '@buildwithsygma/sygmaprotocol-react-widget'; + +function MyDapp(){ + return ( + ; + ) +} +``` + +You can also pass props to the widget component to customize it: + +```ts +function MyDapp(){ + return ( + + ) +} +``` + +See [widget.ts](https://github.com/sygmaprotocol/sygma-widget/blob/main/packages/widget/src/widget.ts) for all of the available properties. \ No newline at end of file diff --git a/docs/04-ecosystem/04-explorer.md b/docs/04-integrating-with-sygma/02-explorer.md similarity index 97% rename from docs/04-ecosystem/04-explorer.md rename to docs/04-integrating-with-sygma/02-explorer.md index bc68600..78b6623 100644 --- a/docs/04-ecosystem/04-explorer.md +++ b/docs/04-integrating-with-sygma/02-explorer.md @@ -1,6 +1,6 @@ --- id: sygma-explorer -slug: /ecosystem/sygma-explorer +slug: /integrating/sygma-explorer title: Sygma Explorer description: The following section provides details on the Sygma explorer. --- diff --git a/docs/04-ecosystem/01-new-token.md b/docs/04-integrating-with-sygma/03-new-token.md similarity index 73% rename from docs/04-ecosystem/01-new-token.md rename to docs/04-integrating-with-sygma/03-new-token.md index 9795f51..d901d19 100644 --- a/docs/04-ecosystem/01-new-token.md +++ b/docs/04-integrating-with-sygma/03-new-token.md @@ -1,17 +1,17 @@ --- id: new-token -slug: /ecosystem/new-token +slug: /integrating/new-token title: Adding A New Token -description: The following section details how to request support for a new token. +description: The following section details how to add new tokens to the Sygma network. --- :::info -The following section details how to request support for a new token. +The following section details how to request support for a new token. The Sygma team is iterating towards permissionless additions of new tokens in the near future. ::: # Token Support -Sygma supports the ERC-20 & ERC-721 token standards, as well as Substrate-native tokens. The currently supported tokens per route (a combination of source and destination network) can be found in our [Environments](../06-environments/01-index.md) page. +Sygma supports the ERC-20 & ERC-721 token standards, as well as native tokens in Substrate. The currently open token routes can be found in our [Environments](../08-resources/01-environments/04-mainnet.md) page. If there is a token that is not yet supported and you would like Sygma to add support, please contact us on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x) - please include answers to the following questions: diff --git a/docs/04-ecosystem/02-new-network.md b/docs/04-integrating-with-sygma/04-new-network.md similarity index 59% rename from docs/04-ecosystem/02-new-network.md rename to docs/04-integrating-with-sygma/04-new-network.md index d23afef..2bc77b4 100644 --- a/docs/04-ecosystem/02-new-network.md +++ b/docs/04-integrating-with-sygma/04-new-network.md @@ -1,17 +1,17 @@ --- id: new-network -slug: /ecosystem/new-network +slug: /integrating/new-network title: Adding A New Network description: The following section details how to request support for a new network. --- :::info -The following section details how to request support for a new network. +The following section details how to request support for a new network. The Sygma team is iterating towards permissionless additions of new networks in the near future. ::: # Network Support -Sygma supports EVM and Substrate-based networks natively. The currently supported networks can be found in the links below. The linked pages also contain information on supported resource types, contract addresses, and available fee schemas: +Sygma currently supports EVM and Substrate-based networks natively, with support for Bitcoin and Cosmos-based ecosystems coming soon. The currently supported networks can be found in the links below. The linked pages also contain information on supported resource types, contract addresses, and available fee schemas: - [Testnet Network Support](https://docs.buildwithsygma.com/environments/testnet/#contract-addresses) - [Mainnet Network Support](https://docs.buildwithsygma.com/environments/mainnet#contract-addresses) diff --git a/docs/04-ecosystem/03-relayer-partner.md b/docs/04-integrating-with-sygma/05-relayer-partner.md similarity index 61% rename from docs/04-ecosystem/03-relayer-partner.md rename to docs/04-integrating-with-sygma/05-relayer-partner.md index 243ffb9..e97fa91 100644 --- a/docs/04-ecosystem/03-relayer-partner.md +++ b/docs/04-integrating-with-sygma/05-relayer-partner.md @@ -1,6 +1,6 @@ --- id: relayer-partner -slug: /ecosystem/relayer-partner +slug: /integrating/relayer-partner title: Becoming A Relayer Partner description: The following section details the process for becoming a relayer partner. --- @@ -9,13 +9,21 @@ description: The following section details the process for becoming a relayer pa The following section details the process for becoming a relayer partner. ::: -# How To Become A Relaying Partner +# Current Relaying Partners: -Currently, Sygma utilizes a permissioned process in order to add new relaying partners. These relayers operate under a trusted federation model. As there is not yet an economic security model that enables trustless participation in the relaying network, this process is required to ensure the security of the network. As the Sygma protocol undergoes decentralization over time, this process will become more and more permissionless. +- [ChainSafe Systems](https://chainsafe.io) +- [Bware Labs](https://bwarelabs.com/) +- [Phala Network](https://phala.network/) +- [Blockops](https://www.blockops.network/) + +New relaying partners will continue to be added over the next months. If you have experience running validators and/or relayers in a professional environment and want to support the decentralization of the Sygma network, please contact us on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x). + +## How To Become A Relaying Partner -For now, relaying partners are selected and onboarded by the Sygma team. For more on relayer deployment, please check out the [related documentation](https://github.com/sygmaprotocol/sygma-relayer-deployment). +Sygma currently utilizes a permissioned approach to integrate new relaying partners, ensuring each entity is meticulously chosen and onboarded by our team. For detailed insights into relayer deployment, we invite you to explore our [related documentation](https://github.com/sygmaprotocol/sygma-relayer-deployment). As we progress towards decentralization and refine our economic security models, the pathway to becoming a relayer partner will evolve to be increasingly permissionless, facilitating trustless participation within the relaying network. ## Acceptance Criteria + Credible entities that wish to participate as a relayer on the Sygma relaying network must meet the following criteria: - Operate commercial validator services - Have proven experience in operating protocol infrastructure for high-security applications @@ -25,11 +33,4 @@ Credible entities that wish to participate as a relayer on the Sygma relaying ne - Must operate on all active mainnet Sygma token routes - Ability & commitment to fulfill service level agreements (SLA) for operating Sygma's relayers as well as meet expectations on service KPI's -## List of current relaying partners: - -- [ChainSafe Systems](https://chainsafe.io) -- [Bware Labs](https://bwarelabs.com/) -- [Phala Network](https://phala.network/) -- [Blockops](https://www.blockops.network/) - New relaying partners will continue to be added over the next months. If you have experience running validators and/or relayers in a professional environment and want to support the decentralization of the Sygma network, please contact us on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x). diff --git a/docs/04-integrating-with-sygma/_category_.json b/docs/04-integrating-with-sygma/_category_.json new file mode 100644 index 0000000..085e73b --- /dev/null +++ b/docs/04-integrating-with-sygma/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Integrating With Sygma", + "position": 4 + } + \ No newline at end of file diff --git a/docs/07-audits/_category_.json b/docs/07-audits/_category_.json deleted file mode 100644 index 35ba1a7..0000000 --- a/docs/07-audits/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Audits", - "position": 7, - "link": { - "type": "doc", - "id": "audits-index" - } -} diff --git a/docs/08-faq.md b/docs/08-faq.md deleted file mode 100644 index 25316d4..0000000 --- a/docs/08-faq.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: FAQs -description: The following section contains frequently asked questions about Sygma ---- - -## FAQs - -### General -1. **Is there a token for Sygma?** - There are no plans for a Sygma token. Please be aware of scams and impersonators that suggest otherwise. - -2. **Where can I find help if I have further questions?** - You can join the Sygma [Discord](https://discord.gg/Qdf6GyNB5J) and ask in any support-related channels. Sygma engineers are generally very responsive to technical queries, and someone will usually be on-call to answer more general questions. - -3. **Do you have any live integrations?** - Sygma is live on Phala's [SubBridge](https://subbridge.io), allowing native token transfers between Ethereum's Mainnet and Phala/Khala. Additionally, with Polkadot's capability for [Cross-Consensus Messaging (XCM)](https://wiki.polkadot.network/docs/learn-xcm) between parachains, users can bridge in and out of [Astar Network](https://astar.network). - -4. **How can I make contributions to Sygma?** - You can submit an application to Sygma's [Contributor Program](https://buildwithsygma.com/contributors) or [Builder Program](https://buildwithsygma.com/builders-program) for medium-to-large effort contributions. - - Sygma is eager for developers to jump into the [GitHub](https://github.com/sygmaprotocol) and help test the code and submit issues. - - Sygma invites engaged participants with high initiative to begin making smaller contributions, whether that's to the [Discord](https://discord.gg/Qdf6GyNB5J), to the [documentation](https://docs.buildwithsygma.com) or by creating content. Make sure to check out the [Contribute](10-contribute.md) page for contributions related to Sygma's documentation. - -### General Support -5. **Is my ecosystem/blockchain/token supported?** - Sygma is currently built to support EVM and Substrate-based chains. The [Solidity contracts](https://github.com/sygmaprotocol/sygma-solidity) and [custom-built pallets](https://github.com/sygmaprotocol/sygma-substrate-pallets) can be adapted to most ecosystems built in these environments, whether that's mainnet Ethereum, an EVM L2, a Polkadot/Kusama parachain, or a standalone Substrate chain. - - If your ecosystem/blockchain/token is not supported (e.g. Tendermint), support could be provided in the near-future. It depends on engineering resources and network demand. If you would like to move ahead with an engineering/product consultation, please contact Sygma on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x). - -6. **Can I add my own networks/tokens?** - The addition of new networks and tokens to the Sygma protocol is currently a permissioned process that must go through the Sygma team. Engineering is already well underway to enable permissionless additions of networks and tokens by the end of 2023. For further inquiries, please contact Sygma on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x). - -7. **Can you build an integration for my project?** - It depends. Please take a look at the documentation for [Adding A New Token](04-ecosystem/01-new-token.md) and [Adding A New Network](04-ecosystem/02-new-network.md). When you are ready, please contact Sygma on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x). - - - -### Protocol -8. **Is the Sygma protocol decentralized?** - In its current state, the Sygma protocol operates under a trusted federation bridging model using a set of off-chain relayers. Research and engineering is already well underway to enable a decentralized and trustless Sygma bridging protocol, which includes governance of the respective governance controls. - -9. **Who are the relayers and what do they do?** - The Sygma protocol relies on a network of trusted off-chain operators that listen for events on a source chain, and "relay" these events to a destination chain through a cryptographic primitive called [secure multi-party computation](https://blog.buildwithsygma.com/multi-party-computation/). You can find a list of Sygma's relaying partners in [Becoming A Relayer Partner](04-ecosystem/03-relayer-partner.md). - -10. **Can I become a relayer for Sygma?** - Sygma is currently looking for credible entities that can meet the acceptance criteria for becoming a relayer. Please see [Becoming A Relayer Partner](04-ecosystem/03-relayer-partner.md) for more information. - - - -11. **What happens when a relayer entity drops off?** - This would be handled by Sygma's "key reshare" sub-protocol. The "Key Reshare" mechanism allows parties from the old set to rotate key shares with new participants without changing the underlying public/private key. This is useful for onboarding new members into the signing committee, recalibrating threshold requirements, and more importantly preventing hackers from corrupting parties one after another, potentially in the course of many sessions (known as proactive adversaries). - -12. **What are the mechanisms for token bridging? Are bridged tokens wrapped or synthetic assets?** - Depending on the integration of the specific token route, bridged tokens will follow either a lock/release (1:1 backed, wrapped asset) mechanism or a burn/mint (synthetic asset) mechanism. - -13. **How is Sygma currently secured?** - The Sygma protocol currently uses secure multi-party computation (MPC) and threshold signature schemes (TSS) to strengthen security and communication within the relayer network. Furthermore, there is ongoing efforts underway to implement optimistic, trust-minimized cross-chain block header oracles (see [Introducing Zipline Casper](https://blog.chainsafe.io/introducing-zipline-casper-6fb6dce44992)), as well as a ZK-based block header oracle to provide tailored security for different bridging use-cases. - -### Widget - -14. **Why do I need two token approvals to confirm a transaction?** - -When initiating a cross-chain transaction using the Sygma widget on EVM-compatible chains, you will encounter two separate prompts for token approvals, followed by a final confirmation request for the transfer. The reason for the two approvals is due to how the Sygma protocol orchestrates fee management and bridging operations across different sets of smart contracts. A deeper look into the two approvals: - - 1. **Fee Approval**: The first approval is directed towards a set of smart contracts that manages fee calculations. This approval grants the fee handling contracts permission to spend up to the necessary amount of fee tokens, which represents the service charge for executing the cross-chain operation. The user does not have to specify the fee amount as the interface will automatically calculate this. The user only needs to approve the specified amount. - 2. **Bridging Transaction Approval**: The second approval is directed towards the bridging smart contract, which oversees the cross-chain transfer of tokens. This approval grants this contract permission to spend (and transfer) up to the specified amount of the given token, less previously calculated fees. Similar to the fee approval, the interface will automatically calculate the amount that needs to be approved for the net token amount to be transferred. The user only needs to approve the specified amount. - -Following the two approvals, the user will need to finalize the cross-chain transaction by clicking on “Transfer” within the Sygma widget interface. - -This two-step approval process ensures 1) appropriate fees are calculated and 2) on the correct amount of tokens to be transferred during a cross-chain execution. You can read more about token approvals and their role in web3 here and here. As token allowances may represent a potential attack vector for improperly secured smart contracts, it is recommended to periodically practice good token hygiene by revoking permissions. - - - diff --git a/docs/06-environments/01-index.md b/docs/08-resources/01-environments/01-index.md similarity index 73% rename from docs/06-environments/01-index.md rename to docs/08-resources/01-environments/01-index.md index f56b4df..d099a93 100644 --- a/docs/06-environments/01-index.md +++ b/docs/08-resources/01-environments/01-index.md @@ -1,7 +1,8 @@ --- -slug: /environments +slug: /resources/environments title: Environments -id: environemnts-index +id: environments-index +sidebar_position: 1 --- :::info The following details a list of deployed smart contract addresses for a variety of environments. diff --git a/docs/06-environments/03-testnet/01-obtain-testnet-tokens.md b/docs/08-resources/01-environments/03-testnet/01-obtain-testnet-tokens.md similarity index 90% rename from docs/06-environments/03-testnet/01-obtain-testnet-tokens.md rename to docs/08-resources/01-environments/03-testnet/01-obtain-testnet-tokens.md index c07609b..ee35a39 100644 --- a/docs/06-environments/03-testnet/01-obtain-testnet-tokens.md +++ b/docs/08-resources/01-environments/03-testnet/01-obtain-testnet-tokens.md @@ -4,7 +4,7 @@ description: The following details how to obtain Testnet tokens from the Faucet # Obtain Testnet Tokens -import App from '../../../src/Faucet/App'; +import App from '../../../../src/Faucet/App'; diff --git a/docs/06-environments/03-testnet/02-adding-tokens-to-metamask.md b/docs/08-resources/01-environments/03-testnet/02-adding-tokens-to-metamask.md similarity index 100% rename from docs/06-environments/03-testnet/02-adding-tokens-to-metamask.md rename to docs/08-resources/01-environments/03-testnet/02-adding-tokens-to-metamask.md diff --git a/docs/06-environments/03-testnet/_category_.json b/docs/08-resources/01-environments/03-testnet/_category_.json similarity index 100% rename from docs/06-environments/03-testnet/_category_.json rename to docs/08-resources/01-environments/03-testnet/_category_.json diff --git a/docs/06-environments/03-testnet/index.md b/docs/08-resources/01-environments/03-testnet/index.md similarity index 95% rename from docs/06-environments/03-testnet/index.md rename to docs/08-resources/01-environments/03-testnet/index.md index 4d05dea..2f42c86 100644 --- a/docs/06-environments/03-testnet/index.md +++ b/docs/08-resources/01-environments/03-testnet/index.md @@ -4,40 +4,51 @@ id: testnet-index description: The following details a list of resources that support the Testnet environment. --- -import SupportedDomains from '../../../src/components/SupportedDomains'; +import SupportedDomains from '../../../../src/components/SupportedDomains'; import { Environment } from '@buildwithsygma/sygma-sdk-core'; :::tip Status -**🟢 Active** +| Verification Mechanism | Status | +|------------------------|-----------------------| +| MPC Relay | **🟢 Active** | +| Spectre | **🟢 Active** | +| Zipline | **🟠 In Development** | ::: The following section details Sygma's testnet deployments, including both MPC and Spectre (zk) verification systems: -- [Testnet transfer UI](#testnet-transfer-ui) -- [Testnet faucet](#testnet-faucet) -- [Supported networks](#supported-networks) -- [EVM contract addresses](#evm-contract-addresses) -- [Registered resources](#registered-resources) -- [Fee schemes](#fee-schemes) +- [Testnet Transfer UI](#testnet-transfer-ui) +- [Testnet Faucet](#testnet-faucet) +- [Supported Networks](#supported-networks) +- [EVM Contract Addresses](#evm-contract-addresses) + - [Sepolia](#sepolia) + - [Cronos Testnet](#cronos-testnet) + - [Holesky](#holesky) + - [Arbitrum Sepolia](#arbitrum-sepolia) + - [Gnosis Chiado](#gnosis-chiado) + - [Base Sepolia](#base-sepolia) + - [Amoy](#amoy) +- [Registered Resources](#registered-resources) +- [Fee Schemes](#fee-schemes) - [Sygma Explorer](#sygma-explorer) -Many of the values found below will be important if you are a developer working with the [Sygma SDK](../../02-sygma-sdk/01-index.md) +You will need to work with these environment values if you are working with the [Sygma SDK](../../../03-sygma-sdk/02-Quick-Start/01-installing-the-sdk.md). -## Testnet transfer UI +## Testnet Transfer UI The [transfer UI](https://sygma-react-widget.pages.dev/) provides users with a visual interface to connect their wallets and bridge tokens. -## Testnet faucet +## Testnet Faucet -The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a visual interface to mint tokens. +The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a visual interface to mint testnet tokens. -## Supported networks +## Supported Networks -## EVM contract addresses +## EVM Contract Addresses -**Sepolia (Domain ID: 2)** +#### Sepolia | Contract | MPC Address | Spectre Address | |--------------------------------|-------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------| @@ -56,7 +67,7 @@ The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a v | Spectre Proxy | | [0xC4c2722e8E35fe95C49036eb0d2Ed15e48341061](https://sepolia.etherscan.io/address/0xC4c2722e8E35fe95C49036eb0d2Ed15e48341061) | | Spectre | | [0xEf7d892E8F5177ED9C8eF140E63948685B15E380](https://sepolia.etherscan.io/address/0xEf7d892E8F5177ED9C8eF140E63948685B15E380) | -**Cronos Testnet (Domain ID: 5)** +#### Cronos Testnet | Contract | Address | | --------------------------------- | ------------------------------------------ | @@ -70,7 +81,7 @@ The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a v | Permissionless Generic Handler | [0x3CBbC542d10CD037cafb1632B29B5B0F59B08A48](https://explorer.cronos.org/testnet/address/0x3CBbC542d10CD037cafb1632B29B5B0F59B08A48) | | Storage (GMP testing contract) | [0xcb9eb2b2abbd51945a82f77e789c26720b3835bf](https://explorer.cronos.org/testnet/address/0xcb9eb2b2abbd51945a82f77e789c26720b3835bf) | -**Holesky (Domain ID: 6)** +#### Holesky | Contract | MPC Address | Spectre Address | |--------------------------------|-------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------| @@ -88,7 +99,7 @@ The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a v | Spectre Proxy | | [0x4D083Cb89698C2CA59cDae9428854073781784A3](https://holesky.etherscan.io/address/0x4D083Cb89698C2CA59cDae9428854073781784A3) | | Spectre | | [0x220aD39E44A3765a791B33c925B8e76B8a665657](https://holesky.etherscan.io/address/0x220aD39E44A3765a791B33c925B8e76B8a665657) | -**Arbitrum Sepolia (Domain ID: 8)** +#### Arbitrum Sepolia | Contract | Address | | --------------------------------- | ------------------------------------------ | @@ -101,7 +112,7 @@ The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a v | Permissionless Generic Handler | [0x5ffB6Dc54221371CcBDb9850A283488e12aDf97D](https://sepolia.arbiscan.io/address/0x5ffB6Dc54221371CcBDb9850A283488e12aDf97D) | | Storage (GMP testing contract) | [0xd2973aca263e088bb3c9c0daf80ae2afebec1386](https://sepolia.arbiscan.io/address/0xd2973aca263e088bb3c9c0daf80ae2afebec1386) | -**Gnosis Chiado (Domain ID: 9)** +#### Gnosis Chiado | Contract | Address | | --------------------------------- | ------------------------------------------ | @@ -113,7 +124,7 @@ The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a v | Permissionless Generic Handler | [0xe4B86b1B07bBdB0C47940b9B3bD4954A0deAdaBE](https://gnosis-chiado.blockscout.com/address/0xe4B86b1B07bBdB0C47940b9B3bD4954A0deAdaBE) | | Storage (GMP testing contract) | [0x38ee9a4590035fc9506600f4d5c3f75fc8d15406](https://gnosis-chiado.blockscout.com/address/0x38ee9a4590035fc9506600f4d5c3f75fc8d15406) | -**Base Sepolia (Domain ID: 10)** +#### Base Sepolia | Contract | Address | | --------------------------------- | ------------------------------------------ | @@ -126,7 +137,7 @@ The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a v | Permissionless Generic Handler | [0xfd69bbfcCbfc832C56Ca1490df48B4baF3DfD376](https://sepolia.basescan.org/address/0xfd69bbfcCbfc832C56Ca1490df48B4baF3DfD376) | | Storage (GMP testing contract) | [0x669f52487ffa6f9abf722082f735537a98ec0e4b](https://sepolia.basescan.org/address/0x669f52487ffa6f9abf722082f735537a98ec0e4b) | -**Amoy (Domain ID: 11)** +#### Amoy | Contract | Address | | --------------------------------- | ------------------------------------------ | @@ -139,7 +150,7 @@ The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a v | Permissionless Generic Handler | [0x1F932B2582c52f939DCfb367A3A42f8A95f66782](https://www.oklink.com/amoy/0x1F932B2582c52f939DCfb367A3A42f8A95f66782) | | Storage (GMP testing contract) | [0x76b6fa3a0165f79aab9918e6193acb9e3bde5cdb](https://www.oklink.com/amoy/0x76b6fa3a0165f79aab9918e6193acb9e3bde5cdb) | -## Registered resources +## Registered Resources **ERC20LRTest** @@ -166,7 +177,7 @@ The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a v | Resource ID | 0x0000000000000000000000000000000000000000000000000000000000001000 | | Sepolia Contract Address | N/A | -**Permissionless generic message** +**Permissionless generic message (MAX_FEE = 1 million)** | Details | Information | | --------------------------------- | ------------------------------------------------------------------ | @@ -182,7 +193,7 @@ The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a v | Base-sepolia Contract Address | N/A | | Amoy Contract Address | N/A | -**Permissionless generic message** +**Permissionless generic message (MAX_FEE = 15 million)** | Details | Information | | --------------------------------- | ------------------------------------------------------------------ | @@ -223,8 +234,8 @@ The [faucet UI](./01-obtain-testnet-tokens.md "mention") provides users with a v | Resource ID | 0x0000000000000000000000000000000000000000000000000000000000000400 | | Sepolia Contract Address | [0xc6DE9aa04eF369540A6A4Fa2864342732bC99d06](https://sepolia.etherscan.io/address/0xc6DE9aa04eF369540A6A4Fa2864342732bC99d06) | | Cronos Contract Address | [0x0d3ce33038a3e9bf940eca6f5eadf355d47d36b3](https://explorer.cronos.org/testnet/address/0x0d3ce33038a3e9bf940eca6f5eadf355d47d36b3) | -## Fee schemes +## Fee Schemes | Network Name | Handler Address | Fee Type | Fee Percent/Amount | Gas Amount | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ---------- | ------------------ | ---------- | diff --git a/docs/06-environments/04-mainnet.md b/docs/08-resources/01-environments/04-mainnet.md similarity index 85% rename from docs/06-environments/04-mainnet.md rename to docs/08-resources/01-environments/04-mainnet.md index 7203cb7..e35f736 100644 --- a/docs/06-environments/04-mainnet.md +++ b/docs/08-resources/01-environments/04-mainnet.md @@ -3,21 +3,32 @@ title: Mainnet description: The following details a list of resources to support the Mainnet environment. --- -import SupportedDomains from '../../src/components/SupportedDomains'; +import SupportedDomains from '../../../src/components/SupportedDomains'; import { Environment } from '@buildwithsygma/sygma-sdk-core'; :::tip Status -**🟢 Active** +| Verification Mechanism | Status | +|------------------------|-----------------------| +| MPC Relay | **🟢 Active** | +| Spectre | **🔴 Inactive** | +| Zipline | **🟠 In Development** | ::: The following section details Sygma's mainnet deployment, including the protocol's: - [Supported networks](#supported-networks) - [EVM contract addresses](#evm-contract-addresses) -- [Registered resources](#registered-resources) -- [Registered routes and associated fee schemes](#registered-routes-and-associated-fee-schemes) + - [Ethereum Mainnet](#ethereum-mainnet) + - [Khala](#khala) + - [Phala](#phala) + - [Cronos](#cronos) + - [Base](#base) + - [Gnosis](#gnosis) + - [Polygon](#polygon) +- [Registered Resources](#registered-resources) +- [Registered Routes And Associated Fee Schemes](#registered-routes-and-associated-fee-schemes) - [Sygma Explorer](#sygma-explorer) -Many of the values found below will be important if you are a developer working with the [Sygma SDK](../02-sygma-sdk/01-index.md). +You will need to work with these environment values if you are working with the [Sygma SDK](../../03-sygma-sdk/02-Quick-Start/01-installing-the-sdk.md). ## Supported networks @@ -25,7 +36,7 @@ Many of the values found below will be important if you are a developer working ## EVM contract addresses -**Ethereum mainnet (Domain ID: 1)** +#### Ethereum Mainnet | Contract | Address | | ---------------------------------- | ------------------------------------------ | @@ -35,7 +46,21 @@ Many of the values found below will be important if you are a developer working | ERC-20 Handler | [0xC832588193cd5ED2185daDA4A531e0B26eC5B830](https://etherscan.io/address/0xC832588193cd5ED2185daDA4A531e0B26eC5B830) | | Permissionless Generic Handler | [0x31282123E7bcd947e2c1Bc364d564839574fAdCD](https://etherscan.io/address/0x31282123E7bcd947e2c1Bc364d564839574fAdCD) | -**Cronos (Domain ID: 4)** +#### Khala + +| Pallet | Address | +|------------------------|--------------------------------------------------| +| Token Reserved Account | 436H4jatj6ntHTVm3wh9zs1Mqa8p1ykfcdkNH7txmjmohTu3 | +| ERC-20 Handler | 5EYCAe5jLbHcAAMKvLFSXgCTbPrLgBJusvPwfKcaKzuf5X5e | + +#### Phala + +| Pallet | Address | +|------------------------|--------------------------------------------------| +| Token Reserved Account | 436H4jatj6ntHTVm3wh9zs1Mqa8p1ykfcdkNH7txmjmohTu3 | +| ERC-20 Handler | 5EYCAe5jLbHcAAMKvLFSXgCTbPrLgBJusvPwfKcaKzuf5X5e | + +#### Cronos | Contract | Address | | ---------------------------------- | ------------------------------------------ | @@ -46,7 +71,7 @@ Many of the values found below will be important if you are a developer working | ERC-20 Handler | [0x13572649779c8e88bcbbF46E38d6AddaFa6Ba4f1](https://cronoscan.com/address/0x13572649779c8e88bcbbF46E38d6AddaFa6Ba4f1) | | Permissionless Generic Handler | [0xB86bAe6A570a52cBc38Cf6Ac6557F169422cDf30](https://cronoscan.com/address/0xB86bAe6A570a52cBc38Cf6Ac6557F169422cDf30) | -**Base (Domain ID: 5)** +#### Base | Contract | Address | | ---------------------------------- | ------------------------------------------ | @@ -57,7 +82,7 @@ Many of the values found below will be important if you are a developer working | ERC-20 Handler | [0xe43F8245249d7fAF46408723Ab36D071dD85D7BB](https://basescan.org/address/0xe43F8245249d7fAF46408723Ab36D071dD85D7BB) | | Permissionless Generic Handler | [0x2e1eE4153ad2F763ab8C612415AcF0DEe02Bc79B](https://basescan.org/address/0x2e1eE4153ad2F763ab8C612415AcF0DEe02Bc79B) | -**Gnosis (Domain ID: 6)** +#### Gnosis | Contract | Address | | ---------------------------------- | ------------------------------------------ | @@ -67,7 +92,7 @@ Many of the values found below will be important if you are a developer working | ERC-20 Handler | [0x89b835B4b01E29C9464860189a394297913fD65B](https://gnosisscan.io/address/0x89b835B4b01E29C9464860189a394297913fD65B) | | Permissionless Generic Handler | [0xde57DEfEe28F0F59C5Ad3B7116B3E98d257f6f27](https://gnosisscan.io/address/0xde57DEfEe28F0F59C5Ad3B7116B3E98d257f6f27) | -**Polygon (Domain ID: 7)** +#### Polygon | Contract | Address | | ---------------------------------- | ------------------------------------------ | @@ -77,12 +102,12 @@ Many of the values found below will be important if you are a developer working | ERC-20 Handler | [0x3eE20f17BC7D07bf3e06a7342C13A29823C22Ad5](https://polygonscan.com/address/0x3eE20f17BC7D07bf3e06a7342C13A29823C22Ad5) | | Permissionless Generic Handler | [0x96eb8544Dd96aF28EeBa9b86a1De6357DAb519F6](https://polygonscan.com/address/0x96eb8544Dd96aF28EeBa9b86a1De6357DAb519F6) | -## Registered resources +## Registered Resources **Phala** | Property | Value | -| --------------------------------- | --------------------------------------------------------------------------------------------------------------------- | +|-----------------------------------|-----------------------------------------------------------------------------------------------------------------------| | Symbol | PHA | | Type | Fungible | | Fee strategy | Fixed Fee | @@ -90,6 +115,7 @@ Many of the values found below will be important if you are a developer working | Bridging Strategy | Lock/Release | | Resource ID | 0x0000000000000000000000000000000000000000000000000000000000000001 | | Ethereum Mainnet Contract Address | [0x6c5bA91642F10282b576d91922Ae6448C9d52f4E](https://etherscan.io/address/0x6c5bA91642F10282b576d91922Ae6448C9d52f4E) | +| Substrate Token Reserved Account | 436H4jatj6ntHTVm3wh9zs1Mqa8p1ykfcdkNH7txmjmohTu3 | **Permissionless generic message** @@ -100,7 +126,7 @@ Many of the values found below will be important if you are a developer working | Bridging Strategy | GMP | | Resource ID | 0x0000000000000000000000000000000000000000000000000000000000000000 | -## Registered routes and associated fee schemes +## Registered Routes And Associated Fee Schemes | Source Network Name | Destination Network Name | Resource | Fee Percent/Amount | Resource ID | | ------------------- | ------------------------ | -------- | ------------------ | ------------------------------------------------------------------ | @@ -121,7 +147,6 @@ Many of the values found below will be important if you are a developer working | Polygon | Cronos | GMP | 1 MATIC | 0x0000000000000000000000000000000000000000000000000000000000000000 | | Polygon | Gnosis | GMP | 1 MATIC | 0x0000000000000000000000000000000000000000000000000000000000000000 | - ## Sygma Explorer The [explorer UI](https://scan.buildwithsygma.com/) provides users with a cross-chain block explorer that scans for mainnet transactions through the Sygma protocol. diff --git a/docs/06-environments/_category_.json b/docs/08-resources/01-environments/_category_.json similarity index 57% rename from docs/06-environments/_category_.json rename to docs/08-resources/01-environments/_category_.json index 28dbc81..b6f30f4 100644 --- a/docs/06-environments/_category_.json +++ b/docs/08-resources/01-environments/_category_.json @@ -1,8 +1,8 @@ { "label": "Environments", - "position": 6, + "position": 1, "link": { "type": "doc", - "id": "environemnts-index" + "id": "environments-index" } } diff --git a/docs/09-resources/02-official-links.md b/docs/08-resources/02-official-links.md similarity index 86% rename from docs/09-resources/02-official-links.md rename to docs/08-resources/02-official-links.md index c302087..edefd15 100644 --- a/docs/09-resources/02-official-links.md +++ b/docs/08-resources/02-official-links.md @@ -19,7 +19,7 @@ description: The following section details official links related to Sygma #### [Testnet Transfer Widget](https://sygma-react-widget.pages.dev/) -#### [Testnet Faucet](../06-environments/03-testnet/01-obtain-testnet-tokens.md) +#### [Testnet Faucet](../08-resources/01-environments/03-testnet/01-obtain-testnet-tokens.md) ## Community diff --git a/docs/08-resources/03-glossary.md b/docs/08-resources/03-glossary.md new file mode 100644 index 0000000..fbbc6e1 --- /dev/null +++ b/docs/08-resources/03-glossary.md @@ -0,0 +1,98 @@ +--- +id: glossary +slug: /resources/glossary +title: Glossary +description: The following section details important glossary terms related to Sygma +--- + +:::info +The following section is broken down into grouped sections. It follows a sequential ordering so that terminologies and concepts might build off each other. +::: + +### Table Of Contents +- [Foundational Language](#foundational-language) +- [Cross-chain Language](#cross-chain-language) +- [Sygma Language](#sygma-language) +- [Tailored Security](#tailored-security) + +## Foundational Language + +**Bridge**: A connection between two blockchain networks, allowing the transfer of data, tokens, or other assets from one chain to another. + +**Network**: Refers to the entirety of a blockchain ecosystem, whether it is a layer 1 (L1) or layer 2 (L2) chain, including nodes, protocols, and technologies, e.g. Ethereum, Polygon, Base, Gnosis, Polkadot, Bitcoin, Cronos, Cosmos, etc. + +**Cross-chain**: Denotes an action that occurs across multiple blockchains. + +**Interoperability**: The ability for different blockchains to transmit data between each other. + +**Source (origin) chain**: Refers to the initial blockchain network from which a transaction, asset, or data originates before being transferred to another chain. + +**Destination (target) chain**: The network to which a transaction, asset, or data is sent from another blockchain, usually in the context of cross-chain transfers or communication. + +**Route**: The bidirectional path a transaction or message can take as it moves between networks or blockchains in a cross-chain operation. A route may involve intermediary chains other than the source and destination. + +**Ethereum Virtual Machine (EVM)**: A computation engine that acts like a decentralized computer, executing smart contracts on the Ethereum network. + +**Substrate**: A modular framework for building blockchains (e.g. Polkadot, Kusama), enabling developers to create purpose-built chains tailored to specific applications (e.g. Phala, Astar). + +**Pallets**: Components in the Substrate framework that encapsulate specific blockchain functionalities, easily integrated into a Substrate-based blockchain. This is roughly equivalent to a smart contract in EVM-based environments. + +**Relay Chain**: The central chain of a parachain network like Polkadot. It provides security and interoperability for all connected parachains. + +**Parachains**: Individual blockchains that run in parallel within the Polkadot or Kusama ecosystem. They connect to the main relay chain to benefit from its security and interoperability features. + +**Cross-consensus message format (XCM)**: A messaging format and language used to communicate between Substrate parachains. + +--- + +## Cross-chain Language + +**Native interoperability**: The ability of a digital asset, like an ERC-20 token, to be transferred across different blockchain networks and operate as the native asset of the receiving ecosystem, without being wrapped or converted into a synthetic representation. This ensures that the asset retains its original properties and functions directly within the new environment’s protocol. + +**Relayers**: Entities in blockchain systems that relay information from one blockchain to another. Instead of operating full nodes, a relayer operator is listening to events on a source or target chain and sending packets of data to and from different blockchains on behalf of the blockchain’s users. + +**Relayer network**: A collection of nodes that facilitate cross-chain communication by transmitting data and transactions between different blockchain networks, using various security mechanisms to ensure data integrity and consistency between each other. + +**Burn-and-mint**: A process in blockchain where tokens are 'burned' or destroyed in one network and an equivalent number of tokens are 'minted' or created in another network, commonly used in pegged token mechanisms. + +**Lock-and-release**: A mechanism in cross-chain transactions where assets are locked in one blockchain and equivalent assets are released in another blockchain. + +**Liquidity provider**: In the cross-chain context, an entity or individual that supplies tokenized assets to a liquidity pool. These assets facilitate cross-chain trading and other financial activities. + +**Generic message passing**: A method for sending arbitrary data and messages between different blockchains or layers within a blockchain, often used in cross-chain communication. + +--- + +## Sygma Language + +**ChainBridge-core**: An extensible cross-chain communication protocol designed to be a framework for cross-chain applications. Sygma extends the foundational Chainbridge-core repo to build its interoperability solution. + +**Handlers**: Functions or mechanisms, implemented with smart contracts or pallets, that manage or direct specific types of operations or data processing in the context of cross-chain transactions. + +**Chain (ChainID)**: A unique identifier for a specific EVM blockchain network, used in transactions to distinguish between different chains and ensure transactions are processed on the correct blockchain. Commonly known `ChainID`'s can be obtained from [Chainlist](https://chainlist.org/). + +**Domain (DomainID)**: Serves a similar purpose to `ChainID` but is specific to the Sygma protocol. It uniquely identifies different domains or environments within Sygma's cross-chain communication framework, ensuring that messages and transactions are correctly routed and processed across different blockchains or segments of the network. `ChainID`'s and `DomainID`'s are registered together, so each `DomainID` is associated with a specific `ChainID`. This information is stored in the chain's storage and you can look up the mappings. + +**Resource (ResourceID)**: This is a unique identifier for an asset (e.g. ERC-20 or generic message) in Sygma. + +--- + +## Tailored Security + +**Verification system**: The modular components within the Sygma protocol stack that verify a blockchain’s consensus algorithm and state. + +**Multi-party computation**: A subfield of cryptography with the goal of creating methods for parties to jointly compute a function over their inputs while keeping those inputs private. + +**Threshold signature schemes**: A digital signature scheme where any _t_ or more signers of a group of _n_ signers can produce signatures on behalf of the group. Threshold cryptography is a cryptosystem that protects information by encrypting it and distributing it among a cluster of fault-tolerant computers. The message is encrypted using a public key, and the corresponding private key is shared amongst the participating parties. With a threshold cryptosystem, in order to decrypt an encrypted message or to sign a message, several parties (more than some threshold number) must cooperate in the decryption or signature protocol. + +**MPC-based relay**: A network of nodes that relay information using multi-party computation (MPC), a cryptographic method that allows multiple parties to confirm the consensus of onchain events. + +**Coprocessor**: An offchain system that offloads heavy computational steps to verify a blockchain state. + +**Zero-knowledge proof (ZKP)**: A ZKP is a cryptographic method that allows one party (the prover) to prove to another party (the verifier) that a statement is true, without revealing any specific information about the statement itself, other than the fact that it’s true. + +**Light client**: A type of blockchain client that does not store or process an entire blockchain’s data. However, it can rely on efficient mechanisms to verify that certain transaction have occurred or that a specific state is correct. + +**Optimistic Fraud proof**: Proof that can be submitted by a network participant to challenge and prove the incorrectness of a fraudulent transaction. + +**Challengers**: Entities or individuals in a blockchain system that can dispute the validity of a transaction, especially in optimistic rollup systems. If a transaction is found to be invalid, the challenger may receive a reward. \ No newline at end of file diff --git a/docs/05-github-repositories.md b/docs/08-resources/04-github-repositories.md similarity index 53% rename from docs/05-github-repositories.md rename to docs/08-resources/04-github-repositories.md index a9c1bd4..f371c00 100644 --- a/docs/05-github-repositories.md +++ b/docs/08-resources/04-github-repositories.md @@ -9,10 +9,17 @@ The following details a list of relevant Sygma repositories. | Repository | Description | Status | | ---- |-------------| ------ | -| [**sygma-solidity**](https://github.com/sygmaprotocol/sygma-solidity) | Smart contracts used by Sygma bridge | Public repository, [audited](audits/); beta. | +| [**sygma-core**](https://github.com/sygmaprotocol/sygma-core) | Contains core Sygma logic implemented in Go | Public repository, [audited](audits/); beta. | +| [**sygma-sdk**](https://github.com/sygmaprotocol/sygma-sdk) | Tools to easily integrate any JS application with protocol Sygma | Public repository; production.| +| [**sygma-solidity**](https://github.com/sygmaprotocol/sygma-solidity) | Smart contracts used by protocol Sygma | Public repository, [audited](audits/); beta. | +| [**sygma-x-solidity**](https://github.com/sygmaprotocol/sygma-x-solidity) | Contains the zk verification contracts used by Sygma Spectre | Public repository, [audited](audits/); beta. | +| [**sygma-substrate-pallets**](https://github.com/sygmaprotocol/sygma-substrate-pallets) | This repo contains several substrate pallet implementation for Sygma protocol | Public repository, [audited](audits/); beta. | | [**sygma-relayer**](https://github.com/sygmaprotocol/sygma-relayer) | Go-implemented relayer service | Public repository, [audited](audits/); beta. | -| [**sygma-sdk**](https://github.com/sygmaprotocol/sygma-sdk) | Tools to easily integrate any JS application with Sygma bridge | Public repository; production.| +| [**spectre-node**](https://github.com/sygmaprotocol/spectre-node) | Go-implemented zk relayer node | Public repository; beta. | +| [**sygma-inclusion-prover**](https://github.com/sygmaprotocol/sygma-inclusion-prover) | Sygma inclusion prover for zk verification | Public repository; beta. | +| [**sygma-widget**](https://github.com/sygmaprotocol/sygma-widget) | Customizable widget for public integration of protocol Sygma | Public repository; beta. | | [**sygma-ui**](https://github.com/sygmaprotocol/sygma-ui) | Application TransferUI that uses sygma-sdk to interact with Sygma smart contracts and blockchains | Public repository; beta. | | [**explorer-ui**](https://github.com/sygmaprotocol/sygma-substrate-pallets) | ExplorerUI is used to track and navigate Sygma ecosystem | Public repository; beta. | +| [**sygma-explorer-indexer**](https://github.com/sygmaprotocol/sygma-explorer-indexer) | Indexer used by the Sygma Explorer | Public repository; beta. | | [**fee-oracle**](https://github.com/sygmaprotocol/sygma-fee-oracle) | Go-implemented service that provides endpoints to Sygma UI for all necessary data related to bridging fees. | Private repository, audit underway (publicly available upon completion); beta. | -| [**sygma-substrate-pallets**](https://github.com/sygmaprotocol/sygma-substrate-pallets) | This repo contains several substrate pallet implementation for Sygma protocol | Public repository, [audited](audits/); beta. | \ No newline at end of file + diff --git a/docs/07-audits/index.md b/docs/08-resources/05-audits.md similarity index 93% rename from docs/07-audits/index.md rename to docs/08-resources/05-audits.md index b982865..e084747 100644 --- a/docs/07-audits/index.md +++ b/docs/08-resources/05-audits.md @@ -1,8 +1,8 @@ --- -id: audits-index -slug: /audits title: Audits description: The following details audit reports related to the various Sygma repositories. +slug: /resources/audits +id: audit-index --- :::info @@ -13,4 +13,4 @@ The following table details the security audit reviews that have been performed | ---- |-------------| ------ | ------- | :----: | | Sept 6, 2022 | [KALOS (prev. HAECHI AUDIT)](https://www.kalos.xyz/) | [sygma-solidity v1.0](https://github.com/sygmaprotocol/sygma-solidity/releases/tag/v1.0.0), [sygma-relayer v1.0](https://github.com/sygmaprotocol/sygma-relayer/releases/tag/v1.0.0) | [Link](/assets/[HAECHI%20AUDIT]%20Sygma%20Audit%20Report%20v1.1.pdf) | ✅ | | May 18, 2023 | [Least Authority](https://leastauthority.com/) | [sygma-solidity v2.3](https://github.com/sygmaprotocol/sygma-solidity/releases/tag/v2.3.0), [sygma-relayer v1.5](https://github.com/sygmaprotocol/sygma-relayer/releases/tag/v1.5.0), [sygma-substrate-pallets v0.2](https://github.com/sygmaprotocol/sygma-substrate-pallets/releases/tag/sygma-bridge-v0.2.0)| [Link](https://leastauthority.com/wp-content/uploads/2023/05/Least_Authority_Sygma_Final_Audit-Report.pdf) | ✅ | -| Mar 22, 2024 | [Veridise](https://veridise.com/) | [Spectre](https://github.com/ChainSafe/Spectre), [Sygma-X-Solidity](https://github.com/sygmaprotocol/sygma-x-solidity) | [Link](/assets/[Veridise]_Chainsafe_Spectre_-_final_report.pdf) | ✅ | +| Mar 22, 2024 | [Veridise](https://veridise.com/) | [Spectre](https://github.com/ChainSafe/Spectre), [Sygma-X-Solidity](https://github.com/sygmaprotocol/sygma-x-solidity) | [Link](/assets/[Veridise]_Chainsafe_Spectre_-_final_report.pdf) | ✅ | \ No newline at end of file diff --git a/docs/09-resources/03-video.md b/docs/08-resources/06-video.md similarity index 84% rename from docs/09-resources/03-video.md rename to docs/08-resources/06-video.md index 0d5b901..3ba993f 100644 --- a/docs/09-resources/03-video.md +++ b/docs/08-resources/06-video.md @@ -15,6 +15,9 @@ description: The following section contains video resources for Sygma #### Workshop 2: Creating Cross-chain Fungible Transfers And Generic Message Passing With The Sygma SDK +#### Workshop 3: Learn To Bridge From Ethereum To Polkadot For Substrate Developers + + ## Explainers #### Cross-chain Conversations Episode 1: What Is Sygma? diff --git a/docs/09-resources/_category_.json b/docs/08-resources/_category_.json similarity index 100% rename from docs/09-resources/_category_.json rename to docs/08-resources/_category_.json diff --git a/docs/09-faq.md b/docs/09-faq.md new file mode 100644 index 0000000..57a33ba --- /dev/null +++ b/docs/09-faq.md @@ -0,0 +1,89 @@ +--- +title: FAQs +description: The following section contains frequently asked questions about Sygma +--- + +## FAQs + +### General +1. **Is there a token for Sygma?** + There are no plans for a Sygma token. Please be aware of scams and impersonators that suggest otherwise. + +2. **Where can I find help if I have further questions?** + You can join the Sygma [Discord](https://discord.gg/Qdf6GyNB5J) and ask in any support-related channels. Sygma engineers are generally very responsive to technical queries, and someone will usually be on-call to answer more general questions. + +3. **Do you have any live integrations?** + Sygma is live on Phala's [SubBridge](https://subbridge.io), allowing native token transfers between Ethereum's Mainnet and Phala/Khala. Additionally, with Polkadot's capability for [Cross-Consensus Messaging (XCM)](https://wiki.polkadot.network/docs/learn-xcm) between parachains, users can bridge in and out of [Astar Network](https://astar.network). + + Sygma is also currently being used as a proof-of-concept for the [Holesky Validator Launchpad](https://validator.faucet.chainsafe.dev/upload). This dApp enables quick testing of an Ethereum validator setup on the Holesky testnet. A small deposit of testnet ether (3.3 testnet eth) from other testnets (e.g. Sepolia, Amoy, Moonbeam Alpha) can be bridged and exchanged for 32 holeskyETH. + + Sygma is also the current backend integration for a proof-of-concept dApp called `multichain-deploy`. This dApp allows testnet developers to deploy to the same contract addresses across multiple blockchains while paying only source chain gas and fees. There is a [Hardhat implementation](https://github.com/ChainSafe/hardhat-plugin-multichain-deploy) and a [Foundry implementation](https://github.com/ChainSafe/foundry-multichain-deploy). + +4. **How can I make contributions to Sygma?** + + You can submit an application to Sygma's [Contributor Program](https://buildwithsygma.com/contributors) or [Builder Program](https://buildwithsygma.com/builders-program) for medium-to-large effort contributions. + + Sygma is eager for developers to jump into the [GitHub](https://github.com/sygmaprotocol) and help test the code and submit issues. + + Sygma invites engaged participants with high initiative to begin making smaller contributions, whether that's to the [Discord](https://discord.gg/Qdf6GyNB5J), to the [documentation](https://docs.buildwithsygma.com) or by creating content. Make sure to check out the [Contribute](10-contribute.md) page for contributions related to Sygma's documentation. + +### General Support +5. **Is my ecosystem/blockchain/token supported?** + Sygma is currently built to support EVM and Substrate-based chains. The [Solidity contracts](https://github.com/sygmaprotocol/sygma-solidity) and [custom-built pallets](https://github.com/sygmaprotocol/sygma-substrate-pallets) can be adapted to most ecosystems built in these environments, whether that's mainnet Ethereum, an EVM L2, a Polkadot/Kusama parachain, or a standalone Substrate chain. + + If your ecosystem/blockchain/token is not supported (e.g. Tendermint), support could be provided in the near-future. It depends on engineering resources and network demand. If you would like to move ahead with an engineering/product consultation, please contact Sygma on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x). + +6. **Can I add my own networks/tokens?** + The addition of new networks and tokens to the Sygma protocol is currently a permissioned process that must go through the Sygma team. Engineering is already well underway to enable permissionless additions of networks and tokens by the end of 2023. For further inquiries, please contact Sygma on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x). + +7. **Can you build an integration for my project?** + It depends. Please take a look at the documentation for [Adding A New Token](./04-integrating-with-sygma/03-new-token.md) and [Adding A New Network](./04-integrating-with-sygma/04-new-network.md). When you are ready, please contact Sygma on [Discord](https://discord.gg/Qdf6GyNB5J) or fill out [this form](https://share.hsforms.com/1K4-T_yaKSp6F06FGk4wsSgnmy2x). + +### Protocol +8. **Is the Sygma protocol decentralized?** + As with all projects in the crypto space, there will always be _some_ trust assumptions. It is important to understand where these trust assumptions may fall. Research and engineering is underway to enable a decentralized and trust-minimized Sygma bridging protocol, which includes governance of the respective governance controls. + + Under [secure multi-party computation](https://blog.buildwithsygma.com/multi-party-computation/), the Sygma protocol uses a _distributed_ set of offchain relayers operating under a trusted federation model. Adding a proper incentivization model as well as permissionless relay is on the roadmap for MPC relay. + + Under [Spectre](../docs/02-sygma-protocol/02-Tailored-Security/03-Spectre/01-spectre-intro.md) verification, in theory, anyone can submit step, rotation, and inclusion proofs. However, should a Spectre relayer go down, it could temporarily affect liveness. + +9. **Who are the relayers and what do they do?** + You can find a list of Sygma's current relaying partners in [Becoming A Relayer Partner](./04-integrating-with-sygma/05-relayer-partner.md). + + The Sygma protocol relies on a network of trusted offchain operators that listen for events on a source chain, parse these events, and following the selected verification mechanism (either MPC, Spectre, or Zipline relay), either perform attestations of events or submit zero-knowledge proofs. These are then posted to the destination chain bridge contract. + +10. **Can I become a relayer for Sygma?** + Sygma is currently looking for credible entities that can meet the acceptance criteria for becoming a relayer. Please see [Becoming A Relayer Partner](./04-integrating-with-sygma/05-relayer-partner.md) for more information. + +11. **What happens when a relayer entity drops off?** + Under MPC, this would be handled by Sygma's "key reshare" sub-protocol. The "Key Reshare" mechanism allows parties from the old set to rotate key shares with new participants without changing the underlying public/private key. This is useful for onboarding new members into the signing committee, recalibrating threshold requirements, and more importantly preventing hackers from corrupting parties one after another, potentially in the course of many sessions (known as proactive adversaries). + + +12. **What are the mechanisms for token bridging? Are bridged tokens wrapped or synthetic assets?** + Depending on the integration of the specific token route, bridged tokens can follow either a lock/release (1:1 backed, wrapped asset) mechanism or a burn/mint (pegged synthetic asset) mechanism. + +13. **How is Sygma currently secured?** + Sygma interoperability is secured by 3 different verification mechanisms. + + Under MPC, [threshold signature schemes (TSS)](../docs/02-sygma-protocol/02-Tailored-Security/02-MPC/03-tss.md) are used to strengthen security and communication within the relayer network. + + Under Spectre, the protocol is secured by cryptographic proofs. Rotation proofs are submitted to follow consensus of the Altair light client protocol and the rotation of the sync committees every 27 hours. Upon detection of a cross-chain event, a step proof is submitted to prove the state root/block header. A final inclusion proof of the finalized source chain block is submitted. If and only if these conditions are satisfied would an execution of a cross-chain interaction be posted to the destination chain. + + For Zipline security, you can read more in [Introducing Zipline Casper](https://blog.chainsafe.io/introducing-zipline-casper-6fb6dce44992). + +### Widget + +14. **Why do I need two token approvals to confirm a transaction?** + +When initiating a cross-chain transaction using the Sygma widget on EVM-compatible chains, you will encounter two separate prompts for token approvals, followed by a final confirmation request for the transfer. The reason for the two approvals is due to how the Sygma protocol orchestrates fee management and bridging operations across different sets of smart contracts. A deeper look into the two approvals: + + 1. **Fee Approval**: The first approval is directed towards a set of smart contracts that manages fee calculations. This approval grants the fee handling contracts permission to spend up to the necessary amount of fee tokens, which represents the service charge for executing the cross-chain operation. The user does not have to specify the fee amount as the interface will automatically calculate this. The user only needs to approve the specified amount. + 2. **Bridging Transaction Approval**: The second approval is directed towards the bridging smart contract, which oversees the cross-chain transfer of tokens. This approval grants this contract permission to spend (and transfer) up to the specified amount of the given token, less previously calculated fees. Similar to the fee approval, the interface will automatically calculate the amount that needs to be approved for the net token amount to be transferred. The user only needs to approve the specified amount. + +Following the two approvals, the user will need to finalize the cross-chain transaction by clicking on “Transfer” within the Sygma widget interface. + +This two-step approval process ensures 1) appropriate fees are calculated and 2) on the correct amount of tokens to be transferred during a cross-chain execution. You can read more about token approvals and their role in web3 here and here. As token allowances may represent a potential attack vector for improperly secured smart contracts, it is recommended to periodically practice good token hygiene by revoking permissions. + + + diff --git a/docs/09-resources/01-glossary.md b/docs/09-resources/01-glossary.md deleted file mode 100644 index 0378d1f..0000000 --- a/docs/09-resources/01-glossary.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: glossary -slug: /resources/glossary -title: Glossary -description: The following section details important glossary terms related to Sygma ---- - -**Burn-and-mint**: A process in blockchain where tokens are 'burned' or destroyed in one network and an equivalent number of tokens are 'minted' or created in another network, commonly used in pegged token mechanisms. - -**Chain (ChainID)**: A unique identifier for a specific EVM blockchain network, used in transactions to distinguish between different chains and ensure transactions are processed on the correct blockchain. Commonly known `ChainID`'s can be obtained from [Chainlist](https://chainlist.org/). - -**ChainBridge-core**: An extensible cross-chain communication protocol designed to be a framework for cross-chain applications. Sygma extends the foundational Chainbridge-core repo to build its interoperability solution. - -**Cross-consensus message format (XCM)**: A messaging format and language used to communicate between consensus systems, particularly within the context of Polkadot/Kusama. - -**Destination (target) chain**: The network to which a transaction, asset, or data is sent from another blockchain, usually in the context of cross-chain transfers or communication. - -**Domain (DomainID)**: Serves a similar purpose to `ChainID` but is specific to the Sygma protocol. It uniquely identifies different domains or environments within Sygma's cross-chain communication framework, ensuring that messages and transactions are correctly routed and processed across different blockchains or segments of the network. `ChainID`'s and `DomainID`'s are registered together, so each `DomainID` is associated with a specific `ChainID`. This information is stored in the chain's storage and you can look up the mappings. - -**Ethereum Virtual Machine (EVM)**: A computation engine that acts like a decentralized computer, executing smart contracts on the Ethereum network. - -**Generic message passing**: A method for sending arbitrary data between different blockchains or layers within a blockchain, often used in cross-chain communication. - -**Handlers**: Functions or mechanisms, implemented with smart contracts or pallets, that manage or direct specific types of operations or data processing in the context of cross-chain transactions. - -**Liquidity provider**: An entity or individual that supplies tokenized assets to a liquidity pool, typically facilitating trading and other financial activities but also used for bridging in cross-chain transactions. - -**Lock-and-release**: A mechanism in cross-chain transactions where assets are locked in one blockchain and equivalent assets are released in another blockchain. - -**MPC-based relayer network**: A network of nodes that relay information using multi-party computation (MPC), a cryptographic method that allows multiple parties to compute a function over their inputs while keeping them private. - -**Network**: Refers to the entirety of a blockchain infrastructure or ecosystem such as nodes, protocols, and technologies e.g. Ethereum Mainnet, Polygon, Base, etc. - -**Pallets**: Components in the Substrate framework that encapsulate specific blockchain functionalities, easily integrated into a Substrate-based blockchain. - -**Parachains**: Individual blockchains that run in parallel within the Polkadot or Kusama ecosystem. They connect to the main relay chain to benefit from its security and interoperability features. - -**Relay Chain**: The central chain of a parachain network like Polkadot. It provides security and interoperability for all connected parachains. - -**Relayers**: Entities in blockchain systems that relay information from one blockchain to another. Instead of operating full nodes, a relayer operator is listening to events on a source or target chain and sending packets of data to and from different blockchains on behalf of the blockchain’s users. - -**Resource (ResourceID)**: This is a unique identifier for an asset (e.g. ERC-20 or generic message) in Sygma. - -**Route**: The bidirectional path a transaction or message can take as it moves between networks or blockchains in a cross-chain operation. - -**Source (origin) chain**: Refers to the initial blockchain network from which a transaction, asset, or data originates before being transferred to another chain. - -**Substrate**: A modular framework for building blockchains (e.g. Polkadot, Kusama), enabling developers to create purpose-built chains tailored to specific applications (e.g. Phala, Astar) diff --git a/docusaurus.config.js b/docusaurus.config.js index 670d0c7..390ebf2 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -58,7 +58,7 @@ const config = { }, items: [ { - href: 'https://github.com/sygmaprotocol/docs', + href: 'https://github.com/sygmaprotocol/', label: 'GitHub', position: 'right', }, @@ -80,11 +80,11 @@ const config = { }, { label: `Environments`, - to: `/environments`, + to: `/resources/environments`, }, { label: `Audits`, - to: `/audits`, + to: `/resources/audits`, }, ], }, diff --git a/static/assets/spectre_lightclient_benchmark.png b/static/assets/spectre_lightclient_benchmark.png new file mode 100644 index 0000000..92371d7 Binary files /dev/null and b/static/assets/spectre_lightclient_benchmark.png differ diff --git a/static/assets/sygma_protocol_stack.png b/static/assets/sygma_protocol_stack.png new file mode 100644 index 0000000..8a5bf26 Binary files /dev/null and b/static/assets/sygma_protocol_stack.png differ diff --git a/static/assets/sygma_spectre_flow.png b/static/assets/sygma_spectre_flow.png new file mode 100644 index 0000000..e63ba03 Binary files /dev/null and b/static/assets/sygma_spectre_flow.png differ diff --git a/static/assets/tailoredsecurity_compare.png b/static/assets/tailoredsecurity_compare.png new file mode 100644 index 0000000..38470ef Binary files /dev/null and b/static/assets/tailoredsecurity_compare.png differ diff --git a/static/assets/zipline-digram.png b/static/assets/zipline-digram.png new file mode 100644 index 0000000..2a31b90 Binary files /dev/null and b/static/assets/zipline-digram.png differ