fix: typos

docs/introduction/Manta-Atlantic.md

@@ -4,9 +4,9 @@ Manta Atlantic is the fastest and most decentralized ZK Layer1 supporting modula
 
 Compared with those zk privacy layers 1 to build a zk smart contract language, Manta Atlantic is focusing more on the ZK compliance privacy layer with real adoption and interoperability to make other projects have privacy functions without dealing with any cryptography work.
 
-Manta Atlantic uses ZKPs to ensure that transfers are executed according to a structured protocol (circuits) while keeping sensitive information (for example, how much money you send or who you send it to) private. Instead of directly publishing those details on-chain, which would ensure that the protocol has been properly executed but leak all private data, the sensitive bits of information act as witnesses in a ZKP system, namely the SNARK Groth16. Then the Ledger runs the verify function on the resulting ZKP against the public inputs and, if it passes, posts the transaction.
+Manta Atlantic uses ZKPs to ensure that transfers are executed according to a structured protocol (circuits) while keeping sensitive information (for example, how much money you send or who you send it to) private. Instead of directly publishing those details on-chain, which would ensure that the protocol has been properly executed but leaks all private data, the sensitive bits of information act as witnesses in a ZKP system, namely the SNARK Groth16. Then the Ledger runs the verify function on the resulting ZKP against the public inputs and, if it passes, posts the transaction.
 
-The Manta’s zk circuit and infrastructure has been developed by two years, it has a public account based address system and an UTXO based private address system, we call it zkAddress. The zkAddress shielded information including sender, receiver, asset ID, and amount. It is the first private address system that is reusable, independent and auditable. Also the first one supports multiple crypto assets/NFTs, which has its own seed phase and can sync on different devices. With Prove Key, users are able to share the certain asset/credential of the zkAddress without leaking privacy.
+The Manta’s zk circuit and infrastructure have been developed for two years, it has a public account based address system and an UTXO based private address system, we call it zkAddress. The zkAddress shielded information including sender, receiver, asset ID, and amount. It is the first private address system that is reusable, independent and auditable. Also the first one supports multiple crypto assets/NFTs, which has its own seed phase and can sync on different devices. With Prove Key, users are able to share the certain asset/credential of the zkAddress without leaking privacy.
 
 
 [Manta Network Extends zkSBT Features to Over 1.5m Web3 Users](https://mantanetwork.medium.com/manta-network-extends-zksbt-features-to-over-1-5m-web3-users-81cadd7ebdbf)

docs/learn/PrivatePayment.md

@@ -1,6 +1,6 @@
 # How Does Private Payment Work?
 
-Manta is all about bringing privacy to the wider blockchain space, and an important part of making privacy practical to use is the construction of simple and powerful privacy primitives. The first and most powerful primitive we are building is _Private Payment_, more specifcally, a _multi-asset decentralized anonymous payment protocol_.
+Manta is all about bringing privacy to the wider blockchain space, and an important part of making privacy practical to use is the construction of simple and powerful privacy primitives. The first and most powerful primitive we are building is _Private Payment_, more specifically, a _multi-asset decentralized anonymous payment protocol_.
 
 ## How Does It Work?
 
@@ -14,7 +14,7 @@ Currently, the formal specification for _Private Payment_ is still closed source
 
 ## Public Ledgers
 
-Most decentralized systems of digital money use what are called _public ledgers_ to keep track of the flow of money. Public ledgers store the current state of every participant's balances, and whenever someone tries to spend from their account, the blockchain will come to consensus on whether this transaction is valid and updates the state. However, to validate a transaction the public ledger needs to know which sender and receiver are participating, and what amount is being transfered. We would like to find a way to avoid this and preserve the privacy of all parties involved in transactions and keep amounts private as well.
+Most decentralized systems of digital money use what are called _public ledgers_ to keep track of the flow of money. Public ledgers store the current state of every participant's balances, and whenever someone tries to spend from their account, the blockchain will come to consensus on whether this transaction is valid and updates the state. However, to validate a transaction the public ledger needs to know which sender and receiver are participating, and what amount is being transferred. We would like to find a way to avoid this and preserve the privacy of all parties involved in transactions and keep amounts private as well.
 
 ## Properties of a Decentralized Anonymous Payment Protocol
 
@@ -41,7 +41,7 @@ This discussion is not entirely self-contained but we will attempt to explain cr
 
 ### Participants (in detail)
 
-- `Alice` (_sender_): a participant that already has access to some assets and is guaranteed by the `Ledger` the ability to spen them.
+- `Alice` (_sender_): a participant that already has access to some assets and is guaranteed by the `Ledger` the ability to spend them.
 - `Bob` (_receiver_): a participant that can be uniquely identified by other _senders_ and will be guaranteed the ability to spend received assets in the future.
 - `Ledger`: represents all public information (the _state_) and the network of validators (_blockchain_) which come to consensus on the private transfer of ownership of assets between _senders_ and _receivers_.
 
@@ -51,7 +51,7 @@ For `Alice` to send her assets to `Bob`, she communicates with the `Ledger` as a
 
 ### Send
 
-`Alice` begins by constructing a special number called $\textsf{SK}_\textsf{E}$, the _ephemeral secret key_, which she will use to represent this unique transfer. She constructs it by taking `Bob`'s _pubic key_, $\textsf{PK}_\textsf{B}$, some public data from the `Ledger`, and some randomness:
+`Alice` begins by constructing a special number called $\textsf{SK}_\textsf{E}$, the _ephemeral secret key_, which she will use to represent this unique transfer. She constructs it by taking `Bob`'s _public key_, $\textsf{PK}_\textsf{B}$, some public data from the `Ledger`, and some randomness:
 
 ![Send Protocol](./resources/send-protocol.png)
 
@@ -77,7 +77,7 @@ The secret key that `Bob` is using for this scanning process must be the one tha
 
 ## Shared Secrets
 
-But how will `Bob` be able to claim is new assets? How will he be able to spend them in the future?
+But how will `Bob` be able to claim his new assets? How will he be able to spend them in the future?
 
 One of the most important cryptographic tools that we can take advantage of here is the _shared secret_. Essentially, we want to find a way to take some information and wrap it up so that only two people have access to it. Getting someone to share a secret with themselves is easy, they just don't tell anyone. But how do we tell someone else our secrets so that only the two of you ever know what it is?
 
@@ -123,7 +123,7 @@ Now we know how `Alice` can communicate to `Bob` the amount of value she has sen
 
 To satisfy this constraint, `Alice` will generate two kinds of certificates, _UTXOs_ and _void numbers_.
 
-A _UTXO_ or _Unspent Transation Output_, is a certificate for the future spending of one of the receivers of a transaction. It is used in some public ledger protocols in the following way:
+A _UTXO_ or _Unspent Transaction Output_, is a certificate for the future spending of one of the receivers of a transaction. It is used in some public ledger protocols in the following way:
 
 1. Prove that `Alice` owns one of the current UTXOs
 2. Drop `Alice`'s UTXO from the `Ledger`

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 assets with privacy built in (`zkAsset`).
 
-Reference: [MantaPay Protocol v1.0.0](https://github.com/Manta-Network/spec/blob/main/manta-pay/spec.pdf)
+Reference: [MantaPay Protocol v1.0.0](https://github.com/Manta-Network/spec/blob/main/manta-pay/spec.pdf)

docs/learn/ZkpChallenge.md

@@ -61,15 +61,15 @@ 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
-   * choose a wallet that support data field, for example, MyCrypto
+2. Submit a transaction with data field in Ethereum
+   * choose a wallet that supports 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)
     and add the hash of the zero-knowledge-proof in the data field.
      ![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?
 

docs/manta-pacific/Quickstart.md

@@ -6,12 +6,14 @@ Get started with exploring the Manta Pacific ecosystem and developing/deploying
 | Category         | Information                                 |
 | ---------------- | ------------------------------------------- |
 | Network Name     | Manta Pacific L2 Rollup                               |
-| Network URL      | https://pacific-rpc.manta.network/http |
+| Network URL      | https://pacific-info.manta.network/ |
+| RPC URL       | https://pacific-rpc.manta.network/http |
+| Websocket URL | wss://pacific-rpc.manta.network/ws     |
 | Chain ID         | 169                                      |
 | Currency Symbol  | ETH                                         |
 
 ### Bridge Assets
 
 You can also [bridge your assets from Ethereum to Manta Pacific](https://pacific-bridge.manta.network/).
 
-[More Network Information](https://pacific.manta.network/)
+[More Network Information](https://pacific.manta.network/)

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 {
     }
     ...
 }
-```
+```

docs/zkShuffle/Circuits/02-TypescriptSDK.md

@@ -54,7 +54,7 @@ Shuffles the deck in game `gameId` and submits a proof on-chain.
 - `gameId` : number
 
 **Return:**
-- `result` : boolean. `True` is shuffle successs, otherwise `False`.
+- `result` : boolean. `True` is shuffle success, otherwise `False`.
 
 ### draw
 ```async draw(gameId: number): Promise<boolean>```[[src]](https://github.com/manta-network/zkShuffle/blob/main/packages/jssdk/src/shuffle/zkShuffle.ts#L280)
@@ -65,7 +65,7 @@ Draws a card in game `gameId`, and submits a proof on-chain.
 - `gameId` : number
 
 **Return:**
-- `result` : boolean. `True` is draw successs, otherwise `False`
+- `result` : boolean. `True` is draw success, otherwise `False`
 
 ### open
 ```async open(gameId: number, cardIds: number[]): Promise<number[]>```[[src]](https://github.com/manta-network/zkShuffle/blob/main/packages/jssdk/src/shuffle/zkShuffle.ts#L361)
@@ -83,7 +83,7 @@ Opens cards specified by `cardIds` and submits a proof on-chain.
 ### openOffchain
 ```async openOffchain(gameId: number, cardIds: number[]): Promise<number[]>```[[src]](https://github.com/manta-network/zkShuffle/blob/main/packages/jssdk/src/shuffle/zkShuffle.ts#L342)
 
-Opens cards specified by `cardIds`. Returns card's original value if open successs, otherwise returns -1 for the card.
+Opens cards specified by `cardIds`. Returns card's original value if open success, otherwise returns -1 for the card.
 > Different from `open` that sends the decryption onchain, `openOffchain` only shows decrypted card on user machine and does not send to blockchain.
 
 **Parameters:**

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 manage shuffled deck and verify 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)