blockworks-foundation
/
pyth-crosschain
mirror of https://github.com/blockworks-foundation/pyth-crosschain.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

fix: typos (#1347) 

* fix typo

* fix typos

* fix typo

* fix typos
This commit is contained in:
omahs 2024-03-11 16:50:28 +01:00 committed by GitHub
parent ce614fa077
commit fc916c6496
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
price_pusher/README.md
View File

@ -207,9 +207,9 @@ It will take a few minutes until all the services are up and running.
## Reliability ## Reliability
You can run multiple instances of the price pusher to increase the reliability. It is better to use You can run multiple instances of the price pusher to increase the reliability. It is better to use
difference RPCs to get better reliability in case an RPC goes down. **If you use the same payer account different RPCs to get better reliability in case an RPC goes down. **If you use the same payer account
in different pushers, then due to blockchains nonce or sequence for accounts, a transaction won't be in different pushers, then due to blockchains nonce or sequence for accounts, a transaction won't be
pushed twiced and you won't pay additional costs most of the time.** However, there might be some race pushed twice and you won't pay additional costs most of the time.** However, there might be some race
condiitons in the RPCs because they are often behind a load balancer than can sometimes cause rejected conditions in the RPCs because they are often behind a load balancer which can sometimes cause rejected
transactions land on-chain. You can reduce the chances of additional cost overhead by reducing the transactions to land on-chain. You can reduce the chances of additional cost overhead by reducing the
pushing frequency. pushing frequency.

4
target_chains/README.md
View File

@ -27,7 +27,7 @@ A basic implementation of pyth on a target chain includes the following pieces o
## What is stored on each contract ## What is stored on each contract
In terms of contract configuration the following states exists on all the implementations: In terms of contract configuration the following states exist on all the implementations:
1. Price feeds: each contract stores the latest values for each price feed 1. Price feeds: each contract stores the latest values for each price feed
2. Wormhole address: wormhole contract to be used for verifying the VAAs 2. Wormhole address: wormhole contract to be used for verifying the VAAs
@ -40,7 +40,7 @@ In terms of contract configuration the following states exists on all the implem
## Wormhole deployments ## Wormhole deployments
In the case that wormhole is not deployed on a new chain we want to deploy pyth on, we need to deploy wormhole too. In the case that wormhole is not deployed on a new chain we want to deploy pyth on, we need to deploy wormhole too.
The deployment process is chain dependant, but should be very similar to how pyth is deployed on the target chain. The deployment process is chain dependent, but should be very similar to how pyth is deployed on the target chain.
After the initial deployment, we need to make sure wormhole configuration is also on the latest version. After the initial deployment, we need to make sure wormhole configuration is also on the latest version.
This is done by running a set of fixed, known VAAs that update the wormhole configurations (guardians sets) on all chains. This is done by running a set of fixed, known VAAs that update the wormhole configurations (guardians sets) on all chains.

2
target_chains/ethereum/contracts/VERIFY.md
View File

@ -34,7 +34,7 @@ ETHERSCAN_KEY=... npm run verify --module=PythUpgradable --contract_address=0x0e
(Note: the network name comes from the `truffle-config.json`). (Note: the network name comes from the `truffle-config.json`).
(Note: In this case, the `ETHERSCAN_KEY` is your snowtrace API key). (Note: In this case, the `ETHERSCAN_KEY` is your snowtrace API key).
**You might need to add the the explorer api keys in [the truffle config](./truffle-config.js) `api_keys`.** Please look at **You might need to add the explorer api keys in [the truffle config](./truffle-config.js) `api_keys`.** Please look at
`truffle-plugin-verify/utils.js` to find the key names. Here is an example: `truffle-plugin-verify/utils.js` to find the key names. Here is an example:
```js ```js

4
target_chains/sui/cli/README.md
View File

@ -46,7 +46,7 @@ The following steps are needed to upgrade our sui contracts:
## Generating the new contract hash: ## Generating the new contract hash:
Run the following command to generate the new hash, make sure the contract addresses are idential to the deployed ones: Run the following command to generate the new hash, make sure the contract addresses are identical to the deployed ones:
```bash ```bash
npm run cli -- generate-digest npm run cli -- generate-digest
@ -65,5 +65,5 @@ Since clients try to fetch the latest version of the package automatically, it's
### FAQ: ### FAQ:
- I'm seeting the error `Transaction has non recoverable errors from at least 1/3 of validators`. What should I do? - I'm seeing the error `Transaction has non recoverable errors from at least 1/3 of validators`. What should I do?
Make sure you have enough funding in the wallet and try again. Usually a more descriptive error message is available in the returned value of the transaction. Make sure you have enough funding in the wallet and try again. Usually a more descriptive error message is available in the returned value of the transaction.