From 30d5d4c9eeee14a234a2b8122f7848a5aa1a1d29 Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 08:34:54 +0200
Subject: [PATCH 01/11] fix typo Celestia.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/concepts/Celestia.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/concepts/Celestia.md b/docs/concepts/Celestia.md
index fa2e48bc..56e4e4c5 100644
--- a/docs/concepts/Celestia.md
+++ b/docs/concepts/Celestia.md
@@ -1,6 +1,6 @@
 # Celestia
 
-Leveraging Celestia‘s [data availability (DA)](https://blockworks.co/news/data-availability-ethereum), Manta Pacific delivers a blazing-fast infrastructure at a fraction of the cost of monolothic L2s. Celestia employs cutting-edge data availability sampling techniques—two-dimensional Reed-Solomon coding and Namespaced Merkle Trees (NMTs)—to address L2 data availability concerns in a trust-minimized manner. By using Celestia as the DA (Data Availability) layer, Manta Pacific can significantly reduce transaction costs for users.
+Leveraging Celestia‘s [data availability (DA)](https://blockworks.co/news/data-availability-ethereum), Manta Pacific delivers a blazing-fast infrastructure at a fraction of the cost of monolithic L2s. Celestia employs cutting-edge data availability sampling techniques—two-dimensional Reed-Solomon coding and Namespaced Merkle Trees (NMTs)—to address L2 data availability concerns in a trust-minimized manner. By using Celestia as the DA (Data Availability) layer, Manta Pacific can significantly reduce transaction costs for users.
 
 ## What is Celestia?
 

From 5ad182d9765a974136f14a0ccd46955ea6e5f5e6 Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 08:42:58 +0200
Subject: [PATCH 02/11] fix typos ZKP.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/concepts/ZKP.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/concepts/ZKP.md b/docs/concepts/ZKP.md
index 257d0dc9..3d1f1bf0 100644
--- a/docs/concepts/ZKP.md
+++ b/docs/concepts/ZKP.md
@@ -4,7 +4,7 @@
 
 The concept of Zero-Knowledge Proofs (ZKPs) was first invented by Shafi Goldwasser, Silvio Micali and Charles Rackoff in their seminal paper, [*The Knowledge Complexity of Interactive-Proof Systems*](https://dl.acm.org/doi/pdf/10.1145/22145.22178) in the 1980s.
 
- Despite being considered as a theoretical breakthrough, even the cryptography community labeled the scheme as impossible in practice when the idea was born. Thanks to many breakthroughs made in the recent years, especially the contribution made by many web3 projects like ZCash and Aztec, we have seen a Moore’s Law style improvement on the performance of zero-knowledge proof systems.
+ Despite being considered as a theoretical breakthrough, even the cryptography community labeled the scheme as impossible in practice when the idea was born. Thanks to many breakthroughs made in recent years, especially the contribution made by many web3 projects like ZCash and Aztec, we have seen a Moore’s Law style improvement on the performance of zero-knowledge proof systems.
 
 ## What is a Zero-Knowledge Proof System?
 A zero-knowledge proof system is a protocol by which someone (the prover) can prove the correctness of a statement to someone else (the verifier) without disclosing any additional information. It consists of the following elements and satisfies the following properties.
@@ -43,12 +43,12 @@ Let us check that the above protocol satisfies the desired properties:
 2. Soundness: A dishonest prover might try to trick the verifier by sending a $y$ in step 1 which is not a square. In that case the verifier would reject the proof in half the cases, when they choose $b = 0$. If $y$ is a square but $x$ is not, the verifier would reject the proof when $b = 1$. A dishonest prover has a $1/2$ probability to trick the protocol on each iteration, so this probability can be made negligible by iterating enough times.
 3. Zero-knowledge: If $b = 0$, the prover does not use $w$ at any point in the proof, it cannot be leaked. If $b=1$, the only place where the prover uses $w$ is in $\pi = w a$, from which the verifier cannot extract $w$ without the knowledge of $a$. As long as the prover does not repeat the above protocol with the same $a$ for different $b$'s, the protocol remains zero-knowledge.
 
-## Succint Non-Interactive Arguments of Knowledge (SNARKs)
+## Succinct Non-Interactive Arguments of Knowledge (SNARKs)
 A particularly important type of ZKP systems are SNARKs. They are zero-knowledge proof systems which satisfy the following extra properties:
 
 * **Argument of knowledge**: The prover wants to prove knowledge of the witness itself. In the example above, the statement would be "*I know a square root of $2$ in $\mathbb{F}_7$*". One can show the protocol above also proves this stronger statement, thus making it an argument of knowledge.
 
-* **Succinctness**: The proof size is constant or logarithmic compared with the circuit size (i.e. the amount of computations) of the statement. The protocol above is also succint, since the proof is just a number in $\mathbb{F}_7$.
+* **Succinctness**: The proof size is constant or logarithmic compared with the circuit size (i.e. the amount of computations) of the statement. The protocol above is also succinct, since the proof is just a number in $\mathbb{F}_7$.
 
 * **Non-Interactive**: Proof generation and proof verification happen in two consecutive rounds: first the prover runs a function $\textsf{prove}$ to generate a proof and then the verifier runs a function $\textsf{verify}$ to verify it. The protocol above is interactive, i.e., it does not satisfy this property because of the continuous communication between prover and verifier.
 

From 097a3907341b21d1b8566a0dcb54ee0162b5f51c Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 08:45:52 +0200
Subject: [PATCH 03/11] fix typos TrustedSetup.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/guides/TrustedSetup.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/guides/TrustedSetup.md b/docs/guides/TrustedSetup.md
index ba986619..a771a7f0 100644
--- a/docs/guides/TrustedSetup.md
+++ b/docs/guides/TrustedSetup.md
@@ -77,7 +77,7 @@ For Powershell modify this to
 ./manta-trusted-setup-x86_64-pc-windows-msvc register
 ```
 
-That's all, you have installed the client and can move to the the next step: Registration.
+That's all, you have installed the client and can move to the next step: Registration.
 
 ### Source Code Installation
 If you prefer to build the client yourself from source code, follow the instructions [here](https://github.com/Manta-Network/manta-rs/tree/main/manta-trusted-setup).
@@ -91,7 +91,7 @@ manta-trusted-setup register
 ```
 (or the appropriate variant if you used the Windows or alternative Linux installation above).
 
-You will be asked for an email address and twitter account.  After providing them you will see output that looks something like this:
+You will be asked for an email address and twitter account.  After providing them you will see an output that looks something like this:
 ![registration prompt](./resources/ts_guide_register.png)
 
 
@@ -135,4 +135,4 @@ Once the server has verified your contribution you will receive a confirmation m
 ## Announcement
 Please finish your contribution by tweeting the message we provided (or posting to other public forums). While this step is not strictly necessary, it improves the security of the ceremony by creating a public record of your contribution.
 
-Thank you for your participation!
\ No newline at end of file
+Thank you for your participation!

From 29eddc8584746176cd878bffaa2b8ea47de83772 Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 08:54:14 +0200
Subject: [PATCH 04/11] fix typos Spec.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/learn/Spec.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/learn/Spec.md b/docs/learn/Spec.md
index 28cb37fc..1e789643 100644
--- a/docs/learn/Spec.md
+++ b/docs/learn/Spec.md
@@ -1,5 +1,5 @@
 # Core Protocol Specification
 
-MantaPay protocol defines a flexible private asset protocol that supports fungible tokens, non-fungible tokens (NFTs), and soul bound tokens (SBTs). MantaPay allows users to use a permenant address (`zkAddress`) to hold, transfer, and convert to public verious blockchain asset with privacy built in (`zkAsset`).
+MantaPay protocol defines a flexible private asset protocol that supports fungible tokens, non-fungible tokens (NFTs), and soul bound tokens (SBTs). MantaPay allows users to use a permanent address (`zkAddress`) to hold, transfer, and convert to public various blockchain asset with privacy built in (`zkAsset`).
 
-Reference: [MantaPay Protocol v1.0.0](https://github.com/Manta-Network/spec/blob/main/manta-pay/spec.pdf)
\ No newline at end of file
+Reference: [MantaPay Protocol v1.0.0](https://github.com/Manta-Network/spec/blob/main/manta-pay/spec.pdf)

From 070a8312414386b0a86f61f04f97b000432c1f35 Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 08:54:52 +0200
Subject: [PATCH 05/11] fix typos ZkpChallenge.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/learn/ZkpChallenge.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/learn/ZkpChallenge.md b/docs/learn/ZkpChallenge.md
index a67b37d7..ab2cdea9 100644
--- a/docs/learn/ZkpChallenge.md
+++ b/docs/learn/ZkpChallenge.md
@@ -61,7 +61,7 @@ We support two ways of submitting proof hashes:
    * put the hash to the remark field (need to add `0x`)
    * submit the extrinsic to Polkadot blockchain, remember the extrinsic id 
    
-2. Submit an transaction with data field in Ethereum
+2. Submit a transaction with data field in Ethereum
    * choose a wallet that support data field, for example, MyCrypto
    * send an ethereum transaction with the hash as the data field, for example, in MyCrypto, click advanced options 
      ![my crypto](./resources/my-crypto-1.png)
@@ -69,7 +69,7 @@ We support two ways of submitting proof hashes:
      ![my crypto data](./resources/my-crypto-2.png)
    * send the transaction on chain 
 
-Next, submit this [form](https://forms.gle/ZpGua9DUmwmYgiGdA) with your addess to receive the award and ZKP.
+Next, submit this [form](https://forms.gle/ZpGua9DUmwmYgiGdA) with your address to receive the award and ZKP.
 
 ## Got Questions?
 

From 5bb55f79db303d61f628aea24e9029b0ed4b8f34 Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 08:57:26 +0200
Subject: [PATCH 06/11] fix typo alloc.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/openzl/alloc.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/openzl/alloc.md b/docs/openzl/alloc.md
index f68f2074..d6f38c71 100644
--- a/docs/openzl/alloc.md
+++ b/docs/openzl/alloc.md
@@ -46,7 +46,7 @@ pub trait Variable<M, COM = ()> {
     fn new_unknown(compiler: &mut COM) -> Self;
 
     /// Allocates a new known value from `this` into the `compiler`. The terminology 
-    /// "known" refers to the fact that we have access to the underyling value during 
+    /// "known" refers to the fact that we have access to the underlying value during 
     /// execution time where we are able to use its concrete value for execution.
     fn new_known(this: &Self::Type, compiler: &mut COM) -> Self;
 }
@@ -115,4 +115,4 @@ This time the compiler was able to compute a ZKP because the variables were allo
 
 As mentioned above, it was useful in this example to separate allocation and manipulation. All manipulation occurs within `fn membership_check`, which takes arguments that are assumed to be already allocated in the `compiler`. This ensured that the same manipulations would be performed on the symbolic and concrete forms of these variables. 
 
-(Of course many new variables are allocated as `fn membership_check` performs its computation, but their values are not provided directly by the prover. Perhaps it is more correct to say that one should separate variable *input* from variable manipulation.)
\ No newline at end of file
+(Of course many new variables are allocated as `fn membership_check` performs its computation, but their values are not provided directly by the prover. Perhaps it is more correct to say that one should separate variable *input* from variable manipulation.)

From 6d86b614d61d81c1cedec4f735fca814684d2b5b Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 09:01:04 +0200
Subject: [PATCH 07/11] fix typo proposal.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/openzl/proposal.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/openzl/proposal.md b/docs/openzl/proposal.md
index 0114d682..05a5ea2c 100644
--- a/docs/openzl/proposal.md
+++ b/docs/openzl/proposal.md
@@ -4,7 +4,7 @@
 
 ## Overview
 
-OpenZL is an open-source library that helps practioners (especially in Web3 space) to develop and deploy secure, high performance zero-knowledge proof code in production. It tries to bridge the gap between low level cryptographic primitives and devlopers' need to build scalable protocols using zero-knowlege proof cryptography securely and quickly. More specifically, many developers today want to leverage zero-knowledge proof systems to build powerful protocols like ZCash/Manta/ZKSync. However, they are facing two less than ideal choices; first, building a protocol using high-level languages like [Circom](https://docs.circom.io) or [Cairo](https://www.cairo-lang.org) loses many performance optimization opportunities, and second, building the protocol directly using libraries like [`arkworks/groth16`](https://github.com/arkworks-rs/groth16), [`zk-garage/plonk`](https://github.com/zk-garage/plonk), or [`microsoft/nova`](https://github.com/microsoft/Nova) requires expertise in cryptography and can be very error-prone. Also, zero-knowledge proof systems are a moving target. There have been many new, and "better", proof systems coming out every 2-3 years ([BCTV](https://eprint.iacr.org/2013/879.pdf) -> [Groth16](https://eprint.iacr.org/2016/260.pdf) -> [Plonk](https://eprint.iacr.org/2019/953) -> [Nova](https://eprint.iacr.org/2021/370)). OpenZL tries to solve this problem by building flexible, proof-system agnostic, and extensible libraries for Web3 practitioners.  
+OpenZL is an open-source library that helps practitioners (especially in Web3 space) to develop and deploy secure, high performance zero-knowledge proof code in production. It tries to bridge the gap between low level cryptographic primitives and developers' need to build scalable protocols using zero-knowlege proof cryptography securely and quickly. More specifically, many developers today want to leverage zero-knowledge proof systems to build powerful protocols like ZCash/Manta/ZKSync. However, they are facing two less than ideal choices; first, building a protocol using high-level languages like [Circom](https://docs.circom.io) or [Cairo](https://www.cairo-lang.org) loses many performance optimization opportunities, and second, building the protocol directly using libraries like [`arkworks/groth16`](https://github.com/arkworks-rs/groth16), [`zk-garage/plonk`](https://github.com/zk-garage/plonk), or [`microsoft/nova`](https://github.com/microsoft/Nova) requires expertise in cryptography and can be very error-prone. Also, zero-knowledge proof systems are a moving target. There have been many new, and "better", proof systems coming out every 2-3 years ([BCTV](https://eprint.iacr.org/2013/879.pdf) -> [Groth16](https://eprint.iacr.org/2016/260.pdf) -> [Plonk](https://eprint.iacr.org/2019/953) -> [Nova](https://eprint.iacr.org/2021/370)). OpenZL tries to solve this problem by building flexible, proof-system agnostic, and extensible libraries for Web3 practitioners.  
 
 OpenZL consists of 3 parts:
 * *Gadget libraries*: a library of gadgets that developers can use as building blocks for their protocols. The initial range of the gadgets includes accumulators (merkle tree with zero-knowledge membership proof), zk-friendly hash functions (poseidon hash), and commitment schemes. The gadget libraries are programmed in `eclair`.
@@ -42,7 +42,7 @@ These gadgets are composable and can be combined to build more powerful protocol
 Embedded Circuit Language And Intermediate Representation (`eclair`) is a shallow embedded DSL within Rust that serves the circuit description language in the OpenZL stack. It has the following design considerations:
 * *Proof system agnostic*: `eclair` is an IR that describes the circuit logic instead of lower-level proof-systems-specific semantics and optimizations.
 * *Unifying native and constraint code*: Writing zero-knowledge proof code in common framework like `arkworks`, it requires programmers to write the same logic twice -- one for constraints generation, one for native execution. This creates a huge burden on developers and is also error-prone. `eclair` solves this problem elegantly (see later an example) by introducing the concept of a "compiler". Developers only need to write the circuit logic in `eclair` once, and it compiles to both native code and constraints. Developers not only write circuit logic once, they also don't have to worry about the disparity between the native code and the constraint generating code (which could certainly be an existing bug in current applications). In addition, `eclair` automatically generates sanity check code for both native execution and constraints generation.
-* *ruling out common errors*: At *compile time*, `eclair` checks that private witnesses stay private and the public inputs stay public. For example, if a circuit implementer that is not using `eclair` misuses private witness allocation, this could cause a leakage of sercret key in the protocol implementation.   
+* *ruling out common errors*: At *compile time*, `eclair` checks that private witnesses stay private and the public inputs stay public. For example, if a circuit implementer that is not using `eclair` misuses private witness allocation, this could cause a leakage of secret key in the protocol implementation.   
 
 Below is an example of a sub-circuit defined in `eclair` (this is Manta testnet V2 code in [manta-rs](https://github.com/Manta-Network/manta-rs)):
 ```rust

From 26f24dca59daab57aaae04e285fc702a425ca535 Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 09:04:04 +0200
Subject: [PATCH 08/11] fix typo 01-ContractInterface.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/zkShuffle/Circuits/01-ContractInterface.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/zkShuffle/Circuits/01-ContractInterface.md b/docs/zkShuffle/Circuits/01-ContractInterface.md
index fb95eb8b..ce9cc442 100644
--- a/docs/zkShuffle/Circuits/01-ContractInterface.md
+++ b/docs/zkShuffle/Circuits/01-ContractInterface.md
@@ -254,7 +254,7 @@ Gets the decryption record (i.e., which players have decrypted this card).
 
 ```function queryAggregatedPk(uint256 gameId) external returns(uint px, uint py)```[[src]](https://github.com/manta-network/zkShuffle/blob/main/packages/contracts/contracts/shuffle/ShuffleManager.sol#L96-L98)
 
-Queries the aggregated public key for card shuffling/dealing in `gameId`-th game. The public key is a elliptic curve point on BN254 G1 curve.
+Queries the aggregated public key for card shuffling/dealing in `gameId`-th game. The public key is an elliptic curve point on BN254 G1 curve.
 
 **Parameters:**
 - ```gameId```: The created shuffle game ID.
@@ -279,4 +279,4 @@ contract Game is IBaseGame {
     }
     ...
 }
-```
\ No newline at end of file
+```

From 7268488ac7e08052be80999a093562c3eb735afc Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 09:06:54 +0200
Subject: [PATCH 09/11] fix typo Overview.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/zkShuffle/Overview.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/zkShuffle/Overview.md b/docs/zkShuffle/Overview.md
index 1b623fc5..de928e6f 100644
--- a/docs/zkShuffle/Overview.md
+++ b/docs/zkShuffle/Overview.md
@@ -17,7 +17,7 @@ This [directory](https://github.com/manta-network/zkShuffle/tree/main/packages/c
 
 ### Solidity Contracts
 
-This [directory](https://github.com/manta-network/zkShuffle/tree/main/packages/contracts/contracts/shuffle) contains contracts that manages shuffled deck and verifies proofs on-chain. It comprises the manager contract, ShuffleManager.sol, as well as supplementary contracts tasked with operations such as encryption and decryption. The manager contract is responsible for creating new games, registering players, checking game states, and performing various operations required for game management. This frees developers from considering technical details such as card shuffling and dealing, such that developers could focuses on game logic contracts. [Read more](/docs/zkShuffle/Circuits/ContractInterface)
+This [directory](https://github.com/manta-network/zkShuffle/tree/main/packages/contracts/contracts/shuffle) contains contracts that manages shuffled deck and verifies proofs on-chain. It comprises the manager contract, ShuffleManager.sol, as well as supplementary contracts tasked with operations such as encryption and decryption. The manager contract is responsible for creating new games, registering players, checking game states, and performing various operations required for game management. This frees developers from considering technical details such as card shuffling and dealing, such that developers can focus on game logic contracts. [Read more](/docs/zkShuffle/Circuits/ContractInterface)
 
 ### Typescript SDK (Alpha)
 

From 3de2224f6d35b386848e371fcf0110f80067190f Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 09:09:25 +0200
Subject: [PATCH 10/11] fix typo Roadmap.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/concepts/Roadmap.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/concepts/Roadmap.md b/docs/concepts/Roadmap.md
index 3d269a5f..3f1413da 100644
--- a/docs/concepts/Roadmap.md
+++ b/docs/concepts/Roadmap.md
@@ -16,7 +16,7 @@ In its current availability, Manta Pacific is an Optimistic Rollup on Ethereum u
 
 On Manta Pacific, developers reap the benefits from Manta’s Universal Circuits and OP Stack’s low gas fee and scalability to build unique ZK-enabled dApps, which is unprecedented in existing Layer 2s. In particular, Manta Pacific provides Universal Circuits for popular use cases (e.g., [card shuffling/dealing](https://github.com/Manta-Network/zkShuffle) and private on-chain voting), solidity smart contracts for on-chain ZK logic, and a typescript SDK for front-end integration.
 
-Based on Manta’s Universal Circuits, developers without a ZK background can easily develop dApps with built-in ZK features from Manta Pacific such that they do not need to spend years of engineer efforts on customizing ZK circuits. Significantly different from Starkware and Aztec which re-design domain-specific language (DSL) for ZK such as Cario and Noir, Manta Pacific achieves EVM equivalence through adopting OP Stack Bedrock’s codebase. Thus, all existing smart contracts on Ethereum can be seamlessly adopted to Manta Pacific while enabling ZK-based features to unveil new application scenarios such as [verifiable private DID/KYC](https://www.binance.com/en/feed/post/458948), ZK-based fully-onchain games, and synergy between DeFi and decentralized private identity including zkSBT-based whitelist and off-ramp.
+Based on Manta’s Universal Circuits, developers without a ZK background can easily develop dApps with built-in ZK features from Manta Pacific such that they do not need to spend years of engineering efforts on customizing ZK circuits. Significantly different from Starkware and Aztec which re-design domain-specific language (DSL) for ZK such as Cario and Noir, Manta Pacific achieves EVM equivalence through adopting OP Stack Bedrock’s codebase. Thus, all existing smart contracts on Ethereum can be seamlessly adopted to Manta Pacific while enabling ZK-based features to unveil new application scenarios such as [verifiable private DID/KYC](https://www.binance.com/en/feed/post/458948), ZK-based fully-onchain games, and synergy between DeFi and decentralized private identity including zkSBT-based whitelist and off-ramp.
 
 ## **Chapter 2: Manta Pacific Alpha II (+Celestia DA)**
 

From ba84c778477bfe78244d2efffd50af1c0b052985 Mon Sep 17 00:00:00 2001
From: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
Date: Sat, 2 Dec 2023 09:11:16 +0200
Subject: [PATCH 11/11] fix typo TrustedSetup.md

Signed-off-by: iwantanode <87604944+tudorpintea999@users.noreply.github.com>
---
 docs/concepts/TrustedSetup.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/concepts/TrustedSetup.md b/docs/concepts/TrustedSetup.md
index 05849699..8ec55fbb 100644
--- a/docs/concepts/TrustedSetup.md
+++ b/docs/concepts/TrustedSetup.md
@@ -37,7 +37,7 @@ In this way the MPC forms a chain of participants who each contribute their own
 
 > It's worth emphasizing: *if at least one single participant in the ceremony is honest then the resulting keys are secure.*
 
-This is where the term "trusted setup ceremony" comes from. *Setup* because it generates necessary infrastructure (prover/verifier keys) for ZKPs. *Ceremony* because it requires many participants to coordinate with each other to carry out the MPC. *Trusted* because the design of this MPC allows us to trust its output as long as we believe that at least one honest person participated.
+This is where the term "trusted setup ceremony" comes from. *Setup* because it generates the necessary infrastructure (prover/verifier keys) for ZKPs. *Ceremony* because it requires many participants to coordinate with each other to carry out the MPC. *Trusted* because the design of this MPC allows us to trust its output as long as we believe that at least one honest person participated.
 
 ## What attacks are possible?
 
@@ -79,4 +79,4 @@ Each Phase 2 ceremony must begin with the output of a Phase 1 ceremony. In our c
 
 Manta Network successfully held the Trusted Setup ceremony in 2022. Ending officially on December 29th, we saw over 13,000 registrations and 4,328 contributions from 177 countries; Manta Network has broken the world record for having [the largest trusted setup in history](https://mantanetwork.medium.com/the-record-breaking-conclusion-of-the-trusted-setup-441382e675d3).
 
-This means that it is unfortunately too late to contribute, but you can nevertheless [verify the results of the ceremony](https://github.com/Manta-Network/manta-rs/blob/main/manta-trusted-setup/README.md).
\ No newline at end of file
+This means that it is unfortunately too late to contribute, but you can nevertheless [verify the results of the ceremony](https://github.com/Manta-Network/manta-rs/blob/main/manta-trusted-setup/README.md).