2ea41b8176
* ethereum: p2w contract -> p2w emitter, fill in essential envs Change-Id: I6fa9364a96738d2cc02ec829a31fedba0586d8e8 commit-id:0a56f1f8 * Add p2w-relay, a p2w-sdk integration test commit-id:6bfab639 * p2w-sdk: Expand README Change-Id: I17cb547d6aaddc240588923561c26d11a787df2e commit-id:6ebd6a22 * p2w-sdk: don't build ETH contracts, only the types Change-Id: I7cbd18328227700635d7688aa24a9671e8919fcd commit-id:adf079f7 * p2w: configurability and sane envs commit-id:f10fd90e * Solitaire: Implement Option<T> support in structs commit-id:31aa12d6 * bridge/governance.rs: Stop pestering about EMITTER_ADDRESS commit-id:d5bd7234 * p2w-attest: price batching This commit introduces support for multiple Pyth product/price pairs per call. The initial maximum batch size is 5 and is enforced using a `P2W_MAX_BATCH_SIZE` constant. solana/pyth2wormhole/program: * On-chain batching logic * Batch message parsing logic solana/pyth2wormhole/client: * Off-chain batching logic - divides any number of symbols into largest possible batches * Use a multi-symbol config file instead of CLI arguments third_party/pyth/p2w-sdk: * Expose batch parsing logic third_party/pyth/p2w-relay: * Comment out target chain calls until ETH contract supports batching * Test the batch parsing function third_party/pyth/p2w_autoattest.py: * Generate and use the symbol config file with pyth2wormhole-client third_party/pyth/pyth_publisher.py: * Add a configurable number of mock Pyth symbols * Adjust HTTP endpoint for multiple symbols commit-id:73787a61 * p2w-attest: mention attestation size in batch This commit ensures that no matter the attestation format, a batch will never contain attestations of different sizes. This guarantee enables forward compatibility by adding new constant-size fields at the end of a batch at all times. An older implementation will simply not consume the remaining newer values while respecting the stated batch member alignment. commit-id:210da230 * pyth2wormhole-client: use fresh blockhashes, harden batch errors This commit makes sure we don't have to deal with expired transactions due to stale blockhashes. The problem existed with larger symbol configs as well as on Solana mainnet. Additionally, the attestation logic now treats transaction errors as non-critical - a failure for a batch does not prevent attestation attempts for batches farther in the queue commit-id:5e704f8b |
||
---|---|---|
.. | ||
contracts | ||
migrations | ||
scripts | ||
test | ||
.dockerignore | ||
.env.fantom.testnet | ||
.env.template | ||
.env.test | ||
1conf.patch | ||
Dockerfile | ||
README.md | ||
VERIFY.md | ||
copy-from-container.sh | ||
devnet_mnemonic.txt | ||
mine.js | ||
package-lock.json | ||
package.json | ||
truffle-config.js | ||
truffle-verify-constants.patch |
README.md
Wormhole bridge - ETH
These smart contracts allow to use Ethereum as foreign chain in the Wormhole protocol.
The Wormhole
contract is the bridge contract and allows tokens to be transferred out of ETH and VAAs to be submitted
to transfer tokens in or change configuration settings.
The WrappedAsset
is a ERC-20 token contract that holds metadata about a wormhole asset on ETH. Wormhole assets are all
wrapped non-ETH assets that are currently held on ETH.
Deploying
To deploy the bridge on Ethereum you first need to compile all smart contracts:
npx truffle compile
To deploy you can either use the bytecode from the build/contracts
folder or the oz cli oz deploy <Contract>
(Documentation).
You first need to deploy one Wrapped Asset
and initialize it using dummy data.
Then deploy the Wormhole
using the initial guardian key (key_x,y_parity,0
) and the address of the previously deployed
WrappedAsset
. The wrapped asset contract will be used as proxy library to all the creation of cheap proxy wrapped
assets.
Testing
For each test run:
Run npx ganache-cli --deterministic --time "1970-01-01T00:00:00+00:00"
to start a chain.
Run the tests using npm run test
User methods
submitVAA(bytes vaa)
can be used to execute a VAA.
lockAssets(address asset, uint256 amount, bytes32 recipient, uint8 target_chain)
can be used
to transfer any ERC20 compliant asset out of ETH to any recipient on another chain that is connected to the Wormhole
protocol. asset
is the asset to be transferred, amount
is the amount to transfer (this must be <= the allowance that
you have previously given to the bridge smart contract if the token is not a wormhole token), recipient
is the foreign
chain address of the recipient, target_chain
is the id of the chain to transfer to.
lockETH(bytes32 recipient, uint8 target_chain)
is a convenience function to wrap the Ether sent with the function call
and transfer it as described in lockAssets
.