merged 0.1 from mvp
This commit is contained in:
spacemandev
commit
12bce8dea0
187
src/SUMMARY.md
187
src/SUMMARY.md
|
|
@ -1,66 +1,127 @@
|
|||
# Summary
|
||||
|
||||
- [Introduction](./introduction/introduction.md)
|
||||
- [What is an xDapp](./introduction/xdapp.md)
|
||||
- [What is Wormhole](./introduction/wormhole.md)
|
||||
- [What is Portal](./introduction/portal.md)
|
||||
- [Wormhole Architecture]()
|
||||
- [Core Bridge Contracts]()
|
||||
- [VAA: Verifiable Action Approval]()
|
||||
- [Guardian]()
|
||||
- [Relayers]()
|
||||
- [Tools]()
|
||||
- [Testnet]()
|
||||
- [Wormhole Explorer]()
|
||||
- [Bridge UI]()
|
||||
- [Tilt]()
|
||||
- [Wormhole SDK]()
|
||||
- [Portal JS Client Transfers]()
|
||||
- [Examples]()
|
||||
- [EVM to Solana Transfer]()
|
||||
- [Polygon to Oasis with Relayers]()
|
||||
- [Portal Payloads]()
|
||||
- [xDapp Development]()
|
||||
- [Tilt Installation](./development/tilt/overview.md)
|
||||
- [MacOS](./development/tilt/mac.md)
|
||||
- [Linux](./development/tilt/linux.md)
|
||||
- [Constants](./development/tilt/constants.md)
|
||||
- [Project Scaffold](./development/scaffold/overview.md)
|
||||
- [EVM]()
|
||||
- [Foundry]()
|
||||
- [Solana]()
|
||||
- [Solana CLI]()
|
||||
- [Anchor]()
|
||||
- [Algorand]()
|
||||
- [Sending Messages](./development/messages/sending/overview.md)
|
||||
- [EVM](./development/messages/sending/evm.md)
|
||||
- [Solana]()
|
||||
- [Algorand]()
|
||||
- [Registering xDapps](./development/messages/registration/overview.md)
|
||||
- [EVM](./development/messages/registration/evm.md)
|
||||
- [Solana]()
|
||||
- [Algorand]()
|
||||
- [Relaying Messages](./development/messages/relaying/overview.md)
|
||||
- [Manual Relays]()
|
||||
- [Rest Relayers]()
|
||||
- [Generic Relayers]()
|
||||
- [Spy Relayer]()
|
||||
- [Receving Messages]()
|
||||
- [EVM]()
|
||||
- [Solana]()
|
||||
- [Algorand]()
|
||||
- [Portal xDapps]()
|
||||
- [Payload 1 Transfers]()
|
||||
- [Payload 2 Attestations]()
|
||||
- [Payload 3 Contract Controlled Transfers]()
|
||||
- [Projects](./projects/summary.md)
|
||||
- [Messenger](./projects/messenger/introduction.md)
|
||||
- [Prerequistes]()
|
||||
- [EVM]()
|
||||
- [Lever Puzzle]()
|
||||
---
|
||||
- [Wormhole Reference]()
|
||||
- [Contracts]()
|
||||
- [Tilt Accounts]()
|
||||
- [RPC Nodes]()
|
||||
[Introduction](./introduction/introduction.md)
|
||||
|
||||
---
|
||||
|
||||
# Overview
|
||||
|
||||
- [xDapps](./dapps/0_xdappOverview.md)
|
||||
|
||||
- [Dapp Ecosystem Basics](./dapps/1_defiBasics.md)
|
||||
- [Cross-Chain Interoperability](./dapps/2_crossChainInteroperability.md)
|
||||
- [xData & xAssets](./dapps/3_xdataxassets.md)
|
||||
- [What is an xDapp?](./dapps/4_whatIsanXdapp.md)
|
||||
- [Advantages of xDapps](./dapps/5_advantages.md)
|
||||
|
||||
- [Wormhole](./wormhole/wormholeOverview.md)
|
||||
- [What is Wormhole?](./wormhole/whatIsWormhole.md)
|
||||
- [Architecture Overview](./wormhole/architectureOverview.md)
|
||||
- [Guardian Network](./wormhole/guardianNetwork.md)
|
||||
- [Core Layer Contracts](./wormhole/coreLayerContracts.md)
|
||||
- [VAA: Verifiable Action Approval](./wormhole/vaa.md)
|
||||
- [Relayers](./wormhole/relayers.md)
|
||||
- [Portal xAsset Bridge](./wormhole/portalTokenBridge.md)
|
||||
- [Wormchain](./wormhole/wormchain.md)
|
||||
|
||||
---
|
||||
|
||||
# xDapp Architecture
|
||||
|
||||
- [xDapp Design]()
|
||||
- [Key Considerations]()
|
||||
- [Ecosystems]()
|
||||
- [EVM]()
|
||||
- [Solana]()
|
||||
- [Cosmos]()
|
||||
- [Algorand]()
|
||||
- [Protocol-First Design]()
|
||||
- [Topology]()
|
||||
- [Hub & Spoke]()
|
||||
- [Mesh]()
|
||||
- [xAssets]()
|
||||
- [Relayers]()
|
||||
- [Generic Relayers]()
|
||||
- [Protocol-Specific Relayers]()
|
||||
- [Security]()
|
||||
- [Trust Assumptions]()
|
||||
- [Layer 1 Risk]()
|
||||
- [Finality Guarantees]()
|
||||
- [Examples]()
|
||||
- [Cross-Chain Swap]()
|
||||
- [Remote Staking]()
|
||||
- [Common Use Cases]()
|
||||
- [FAQ]()
|
||||
|
||||
---
|
||||
|
||||
# xDapp Development
|
||||
|
||||
- [Before You Start]()
|
||||
- [Choosing an Environment]()
|
||||
- [Tilt Installation](./development/tilt/overview.md)
|
||||
- [MacOS](./development/tilt/mac.md)
|
||||
- [Linux](./development/tilt/linux.md)
|
||||
- [Constants](./development/tilt/constants.md)
|
||||
- [Project Scaffold](./development/scaffold/overview.md)
|
||||
- [EVM]()
|
||||
- [Foundry]()
|
||||
- [Solana]()
|
||||
- [Solana CLI]()
|
||||
- [Anchor]()
|
||||
- [Algorand]()
|
||||
- [Sending Messages](./development/messages/sending/overview.md)
|
||||
- [EVM](./development/messages/sending/evm.md)
|
||||
- [Solana]()
|
||||
- [Algorand]()
|
||||
- [CosmWasm]()
|
||||
- [Registering xDapps](./development/messages/registration/overview.md)
|
||||
- [EVM](./development/messages/registration/evm.md)
|
||||
- [Solana]()
|
||||
- [Algorand]()
|
||||
- [CosmWasm]()
|
||||
- [Relaying Messages](./development/messages/relaying/overview.md)
|
||||
- [Manual Relays]()
|
||||
- [Rest Relayers]()
|
||||
- [Spy Relayer]()
|
||||
- [Generic Relayers]()
|
||||
- [Receving Messages]()
|
||||
- [EVM]()
|
||||
- [Solana]()
|
||||
- [Algorand]()
|
||||
- [CosmWasm]()
|
||||
- [Projects](./projects/summary.md)
|
||||
- [Messenger](./projects/messenger/introduction.md)
|
||||
- [Prerequistes]()
|
||||
- [EVM]()
|
||||
- [Lever Puzzle]()
|
||||
- [Tools]()
|
||||
- [Testnet]()
|
||||
- [Wormhole Explorer]()
|
||||
- [Bridge UI]()
|
||||
- [Tilt]()
|
||||
- [Wormhole SDK]()
|
||||
|
||||
---
|
||||
|
||||
# Portal Token Bridge
|
||||
|
||||
- [Portal]()
|
||||
- [Portal JS Client Transfers]()
|
||||
- [Payload 1 Transfers]()
|
||||
- [Payload 2 Attestations]()
|
||||
- [Payload 3 Contract Controlled Transfers]()
|
||||
- [Examples]()
|
||||
- [EVM to Solana Transfer]()
|
||||
- [Polygon to Oasis with Relayers]()
|
||||
- [Portal Payloads]()
|
||||
|
||||
---
|
||||
|
||||
# Other Resources
|
||||
|
||||
- [Glossary]()
|
||||
- [Reference]()
|
||||
- [Github & Useful Links](./reference/github.md)
|
||||
- [Deployed Contracts](./reference/contracts.md)
|
||||
- [RPC Nodes](./reference/rpcnodes.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,3 @@
|
|||
As a first order of business, let's go over the current state of the De-Fi ecosystem, the emerging role of xDapps, and what advantages they have over conventional Dapps.
|
||||
|
||||
By the end of this chapter, you should have a clear understanding of what xDapps are, and why they are gaining so much traction in the blockchain development community.
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
# Dapp Basics
|
||||
|
||||
The fundamental starting point for any decentralized computing discussion is, of course, the blockchain.
|
||||
|
||||
Since the launch of Bitcoin in 2009, the cryptocurrency and decentralized computing ecosystem has evolved and expanded year-over-year, to the point where it now includes hundreds of blockchains, often also referred to as **Layer 1s**.
|
||||
|
||||
Somewhat newer, however, is the concept of a **Decentralized Application** or **Dapp**, which only came into being in 2015 with the launch of Ethereum and 'smart contracts'. Prior to the introduction of smart contracts, blockchain transactions were limited in their capacities, and could more-or-less only transfer funds from point A to B. Smart contracts allow developers to perform arbitrary on-chain computation as part of a blockchain transaction. This feature opened the door for blockchain technology to become a global general-purpose computing platform, rather than just a simple history of token transfers.
|
||||
|
||||
In the introvening years, a rich ecosystem of Dapps has cropped up across the myriad of smart-contract-enabled blockchains. These Dapps provide a wide array of services, and in some cases have created entirely new products. Dapps fall into categories such as:
|
||||
|
||||
- Decentralized Exchanges (DEXs)
|
||||
- Decentralized Autonomous Organizations (DAOs)
|
||||
- Borrow-Lend Platforms
|
||||
- Decentralized Games
|
||||
- NFT Protocols
|
||||
- Metaverse Platforms
|
||||
- and more
|
||||
|
||||
However, today's Dapps are not without their limitations, and many of these limitations are tied to the underlying blockchains themselves.
|
||||
|
||||
Two key limitations of baseline blockchain technology is that it has no access to off-chain data, and also no mechanism to interact with other blockchains. These limitations have lead to a fractured ecosystem, where each blockchain is - by default - siloed off from the others. Assets native to Polygon are not accessible on Ethereum, and services like Uniswap can't be leveraged on Solana.
|
||||
|
||||
This is obviously not a desireable state of the world, and blockchain developers are now aiming to solve these interoperability problems in order to create a better, more unified ecosystem where the gory details of each blockchain are abstracted away. In this new cross-chain ecosystem, people stop being "Ethereum" or "Solana" users, and simply become Web3 users.
|
||||
|
||||
In the next section, we'll discuss the history and challenges of cross-chain interoperability, as well as introduce the role Wormhole plays in the future of this space.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# Cross-Chain Interoperability
|
||||
|
||||
The fact that each cryptocurrency is locked to its own chain has been a limitation of blockchains since day one. It's not 'real' Bitcoin unless it's on the Bitcoin ledger, and it's not 'your' Bitcoin unless you have the private keys to the wallet.
|
||||
|
||||
This restriction is fine if you're content with just sending Bitcoin around, but it becomes a major obstacle as soon you want to exchange Bitcoin for any other currency.
|
||||
|
||||
The first attempt at solving this problem was by creating cryptocurrency exchanges, such as Coinbase and Binance. Today these are refered to as centralized exchanges, or CEXs.
|
||||
|
||||
Centralized Exchanges play an important role in the cryptocurrency space, but they are certainly not a silver bullet for cross-chain interoperability. This is primarily due to two reasons.
|
||||
|
||||
1. They're centralized, which directly defeats the purpose of creating a decentralized platform in the first place.
|
||||
2. They deal only with tokens. As blockchains move away from being a simple history of token transfers, and towards being general purpose computing platforms, interoperability will involve much more complex data structures than 'tokens', and much more sophisticated operations than 'transfers'.
|
||||
|
||||
To solve the centralization problems associated with CEXs, the DEX was born. A DEX operates inside a smart contract runtime, and therefore can be as decentralized as the blockchain it runs on. Unfortunately, a DEX is only able to utilize the tokens which exist on its native blockchain, so in order to obtain a token which is not native to the blockchain, the DEX must be used in combination with a **bridge**.
|
||||
|
||||
**Bridges** are a complex beast which will be discussed in depth later. For now, we can simply categorize bridges as applications which 'lock' assets on one chain in exchange for **wrapped assets** on another chain. The wrapped assets can, in turn, be exchanged for the original 'backing' asset.
|
||||
|
||||
Here are some other key things to understand about bridges:
|
||||
|
||||
- Bridges are currently the only way to custody a token on a chain other than its 'native' chain. If you're holding ETH on some chain other than Ethereum, it is, _by definition_, a wrapped token.
|
||||
- Generally, wrapped tokens become 'double wrap' when they traverse multiple bridges or blockchains. This creates a lengthy unwrapping process to get back to the original token.
|
||||
- Bridges are all mutually incompatible with eachother.
|
||||
- Bridges are capable of being decentralized in theory, but are often quite centralized in practice.
|
||||
|
||||
This brief history explains how we arrived at where we are today. CEXs are a simple solution to siloed blockchains, DEXs are a simple response to CEXs, and once you have DEXs, bridges become necessary infrastructure. Each solution in this timeline is an ad-hoc patch to the previous problem, and the current landscape of fractured liquidity, double-wrapped tokens, isolated userbases, and wallet incompatibilities is a result of this.
|
||||
|
||||
The way to address these issues is not to slap another bandage on top, but rather to go back to the drawing board, and design new primatives and core infrastructure which will allow the next generation of decentralized applications to never suffer from these problems in the first place.
|
||||
|
||||
Wormhole is an attempt to do just this. It looks at the budding decentralized computing ecosystem and proposes a new way of developing applications which leverages the strengths of each blockchain while mitigating the problems which have thusfar plagued the ecosystem.
|
||||
|
||||
The first step in this endeavor is to dethrone the 'token' as the fundamental atomic unit of blockchains, and instead to think of these platforms as global computers which operate on data. This new atomic unit is called **xData**, and we'll talk more about it in the next section.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
# xData and xAssets
|
||||
|
||||
One of the biggest items on the wishlist of features for blockchains is the ability to detach tokens from their native chains. It is a tremendous limitation that ETH only exists on Ethereum, MATIC only exists on Polygon, and SOL only exists on Solana. It would be much more convenient if those assets existed independently of their blockchains, and were able to move freely.
|
||||
|
||||
This is the concept of an **xAsset**, and it should be thought of as the next-generation _wrapped token_. The key feature of an xAsset is that it is chain and path agnostic, and thus retains fungibility regardless of where it travels. xAssets can move fluidly around the blockchain ecosystem without ever becoming double-wrapped. In a sense, xAssets are abstracted to a layer _outside_ of the blockchain ecosystem, and are then able to transact on whatever blockchain is most sensible.
|
||||
|
||||
Once you've envisioned this next-generation asset, you might think it's an excellent atomic unit for solving interoperability. However, this idea is just one step short of the real solution. Blockchains process arbitrary data nowadays, and some of that data just happens to represent assets. The full solution then - is to invent **xData**.
|
||||
|
||||
**xData** is akin to an xAsset, in that it exists in its own layer independent of any blockchain, which is then accessible by _all_ blockchains. The only difference is that it represents arbitrary data, rather than token information.
|
||||
|
||||
Cross-chain interoperability then reduces to the problem of creating and consuming xData. Once blockchains are able to read and write into this xData layer, xAssets are simply a use-case, and come as almost a natural consequence. If you have the ability to read and write data into a shared, global reservior, you can design any application you can imagine.
|
||||
|
||||
In chapter 2 we'll delve deeper into how Wormhole implements this xData layer (also referred to as the 'Core' layer of Wormhole), but for now let's move on to how xDapps can be created on top of it.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
cross chain applications, but more crucially, applications which are built for a cross-chain world. Leverage the strengths of each blockchain.
|
||||
Utilize xData to design powerful decentralized protocols which view individual blockchains as implementation details. xAssets are divorcible from the app and can move tokens across the ecosystem and custody on any chain.
|
||||
|
||||
# What is an xDapp
|
||||
|
||||
The term **xDapp** is short for "Cross-Chain Decentralized Application". At first glance, this might give the impression that xDapps are simply Dapps which meddle a bit in doing cross-chain things. However, once you get into the business of building decentralized products which are designed to operate across a variety of blockchains and runtimes, you begin to see that these applications are architected in a fundamentally different fashion than traditional Dapps.
|
||||
|
||||
The Wormhole Core Layer implements xData, which acts as a shared repository of data across the entire Wormhole Ecosystem. xDapps have the capacity to perform all the operations of traditional Dapps, but they also utilize this xData. This xData allows xDapp developers to build from a top-down, message-passing approach, rather than the bottom-up world of Dapp developers.
|
||||
|
||||
Something we'll dive deeper into during the xDapp Architecture chapter is the philosophy of **Protocol-First Design**. Protocol First Design is an approach to building decentralized applications whereby the first order of business is to lay out your application into a series of data structures, APIs, and message payloads. Once you've laid out your application into a high-level protocol, the protocol acts as an agreement to which all of your components must adhere. From there, the smart contracts underlying this protocol can be considered an implementation detail.
|
||||
|
||||
If you're familiar at all with web2 development, you'll immediately notice that this philosophy is quite analogous to microservice architecture. This is no coincidence, as similar problems should expect to be solved by similar solutions, and the Wormhole Core Layer is quite analogous to the OSI Network Model in many ways.
|
||||
|
||||
Thus, a more fitting depiction of xDapps might be to see them as **Distributed Decentralized Applications**, which have multiple, specialized components working in unison to implement a protocol which delivers a smooth, unified user experience across a variety of layer 1 ecosystems.
|
||||
|
||||
---
|
||||
|
||||
So far we've taken a really high-level and abstract approach to explaining what xDapps are. In the next section we'll get back to real world, and summarize the concrete advantages which xDapps built on Wormhole have over traditional apps today.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
Let's wrap up our discussion of xDapps by highlighting the features they enable, and how they move the ball forward in blockchain technologies.
|
||||
|
||||
- **Expanded User Base** - rather than being limited to the users of one blockchain, any user on any blockchain in the supported ecosystem can interact with an xDapp.
|
||||
|
||||
- **Unified Liquidity** - Liquidity fragmentation is a major problem in the current ecosystem. xAssets, unlike traditional tokens, can be pooled and moved anywhere necessary.
|
||||
|
||||
- **Decentralization** - Cross-chain solutions today usually involve highly centralized exchanges or bridges. Wormhole has been designed to be decentralized from day one, and eventually totally trustless.
|
||||
|
||||
- **Increased Performance** - xDapps are able to utilize the strengths of each blockchain. Expensive computations can be offloaded onto high-performance platforms. Final settlement can be on the preferred chain of the user. Data can be stored wherever is cheapest.
|
||||
|
||||
- **Broader Market Reach** - Because xAssets move freely through the ecosystem, they can be listed on a variety of exchanges, and custodied on any blockchain.
|
||||
|
||||
- **Increased Extensibility and Composeability** - xDapps expand upon the composeability and openness of smart contracts. xDapps can utilize anything across the ecosystem, including other xDapps.
|
||||
|
||||
- **Future Proofing** - As new environments and protocols join the decentralized ecosystem, the connected nature of the Wormhole ecosystem allows existing protocols to expand and support them.
|
||||
|
||||
Now that you have an understanding of what xDapps are and the advantages they offer, let's move on to the next chapter, where we will delve into the nitty gritty of how Wormhole works, and how it enables the creation of these next-generation protocols.
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
# Receving Messages on EVM
|
||||
|
||||
To receive messages in EVM we need to implement a function `receiveMsg`. The name of this function is arbitrary, any function name works as long as the your relayer knows what to call on the application contract when submitting messages.
|
||||
|
||||
This function will take in and encoded set of `bytes` as the VAA and then call the `parseAndVerifyVM` function on the Core Bridge to validate the message.
|
||||
|
||||
```solidity
|
||||
|
||||
function receiveEncodedMsg(bytes memory encodedMsg) public {
|
||||
(IWormhole.VM memory vm, bool valid, string memory reason) = core_bridge.parseAndVerifyVM(encodedMsg);
|
||||
|
||||
//1. Check Wormhole Guardian Signatures
|
||||
// If the VM is NOT valid, will return the reason it's not valid
|
||||
// If the VM IS valid, reason will be blank
|
||||
require(valid, reason);
|
||||
|
||||
//2. Check if the Emitter Chain contract is registered
|
||||
require(_applicationContracts[vm.emitterChainId] == vm.emitterAddress, "Invalid Emitter Address!");
|
||||
|
||||
//3. Check that the message hasn't already been processed
|
||||
require(!_completedMessages[vm.hash], "Message already processed");
|
||||
_completedMessages[vm.hash] = true;
|
||||
|
||||
//Process the message. In this case, we just store the string in the VAA to storage
|
||||
current_msg = string(vm.payload);
|
||||
}
|
||||
|
||||
```
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
# Overview of Receving Messages
|
||||
|
||||
The basic flow of receving messages requires you (or a relayer!) to submit the VAA to your application contract. This contract then calls the Core Bridge on the receving chain to check the message signatures against the stored guardian set signatures.
|
||||
|
||||
If those checks pass, then the application can check to see if it's a message that's already been processed before by checking it's sequence number against a store list of processed message sequence numbers.
|
||||
|
||||
The final optional check is to make sure that the message came from an application from the source chain that we were expecting. Usually this is our own application, and should be registered during initialization steps (see [registration](../registration/overview.md)).
|
||||
|
||||
After we have ensured all those things are correct, we can go ahead and process the message according to the business logic in our application.
|
||||
|
|
@ -14,7 +14,7 @@ The handlers folder contains the js client code to deal with each chain's specif
|
|||
|
||||
They all take in a context object that's made up of the
|
||||
|
||||
### starter.js
|
||||
### orchestrator.js
|
||||
This file parses command line args and filters calls to chain management handlers.
|
||||
|
||||
### xdapp.config.json
|
||||
|
|
|
|||
|
|
@ -1,13 +1,19 @@
|
|||
# Introduction
|
||||
|
||||
> **_NOTE:_** This book is a work in progress. To get a fuller picture of wormhole, also check out [a previous version of these documents](https://docs.wormholenetwork.com/wormhole/).
|
||||
## Welcome to the Wormhole xDapp Book!
|
||||
|
||||
Welcome to the xDapp Book and beginning your journey to be a cross-chain developer. As crypto ecosystems mature, more and more applications will need to interact with programs outside the infrastructure they are deployed on. In Web2 we see this every day, as infrastructure like Azure, GCP, and AWS is abstracted away from the everyday user and applications can freely talk to each other over HTTP.
|
||||
This guide aims to help you in your journey as a cross-chain developer by explaining the core concepts of Wormhole and xDapp development.
|
||||
|
||||
For blockchain applications to unlock their true potential, they too must be able to talk to applications on various infrastructure using a common language. These cross chain applications (xDapps) give rise to cross chain data (xData) and cross chain assets (xAssets). With these powerful primitives, blockchain applications can deliver on their promise of interoperability and composability.
|
||||
We'll start off by outlining the most important aspects of Wormhole, and the considerations which must be taken when developing an xDapp. After that, the second portion of the book helps you set up a development environment and get started writing actual code.
|
||||
|
||||
Ready to step *into the wormhole*?
|
||||
By the end of this guide, you should be ready to build and deploy your first xDapp!
|
||||
|
||||
While this document doesn't assume you have experience with any particular technologies, a general understanding of blockchain development will help you get up to speed.
|
||||
|
||||
Ready to step _into the wormhole_?
|
||||
|
||||
---
|
||||
Check out the [github repository](https://www.github.com/certusone/xdapp-book) of these docs to find the accompanying code in the projects/ directory.
|
||||
|
||||
Check out this project's [github repository](https://www.github.com/certusone/xdapp-book) to find the accompanying code examples.
|
||||
|
||||
See the **Reference** section for additional resources as well.
|
||||
|
|
|
|||
|
|
@ -1,3 +0,0 @@
|
|||
# What is an xDapp
|
||||
|
||||
xDapps are *cross chain decentralized applications*. In short, unlike traditional blockchain programs which are tied to a specific chain, xDapps take advantage of *bridges* like Wormhole to be able to interact with applications from other networks.
|
||||
|
|
@ -0,0 +1,119 @@
|
|||
# Contracts
|
||||
|
||||
Here you can find the addresses for the deployed contracts on all the chains that Wormhole supports, including Testnet.
|
||||
The SDK makes these addresses available in the `CONTRACTS` constant.
|
||||
|
||||
## Mainnet
|
||||
|
||||
### Core Bridge
|
||||
|
||||
| Chain Name | Wormhole Chain ID | Network ID | Address |
|
||||
| :-------------------- | :---------------- | :----------- | :------ |
|
||||
| Solana | 1 | mainnet-beta | worm2ZoG2kUd4vFXhvjh93UUH596ayRfgQ2MgjNMTth |
|
||||
| Ethereum | 2 | 1 | 0x98f3c9e6E3fAce36bAAd05FE09d375Ef1464288B |
|
||||
| Terra | 3 | columbus-5 | terra1dq03ugtd40zu9hcgdzrsq6z2z4hwhc9tqk2uy5 |
|
||||
| Binance Smart Chain | 4 | 56 | 0x98f3c9e6E3fAce36bAAd05FE09d375Ef1464288B |
|
||||
| Polygon | 5 | 137 | 0x7A4B5a56256163F07b2C80A7cA55aBE66c4ec4d7 |
|
||||
| Avalanche (C-Chain) | 6 | 43114 | 0x54a8e5f9c4CbA08F9943965859F6c34eAF03E26c |
|
||||
| Oasis (Emerald) | 7 | 4262 | 0xfE8cD454b4A1CA468B57D79c0cc77Ef5B6f64585 |
|
||||
| Aurora | 9 | 1313161554 | 0xa321448d90d4e5b0A732867c18eA198e75CAC48E |
|
||||
| Fantom | 10 | 250 | 0x126783A6Cb203a3E35344528B26ca3a0489a1485 |
|
||||
| Karura | 11 | 686 | 0xa321448d90d4e5b0A732867c18eA198e75CAC48E |
|
||||
| Acala | 12 | 787 | 0xa321448d90d4e5b0A732867c18eA198e75CAC48E |
|
||||
| Klaytn | 13 | 8217 | 0x0C21603c4f3a6387e241c0091A7EA39E43E90bb7 |
|
||||
| Celo | 14 | 42220 | 0xa321448d90d4e5b0A732867c18eA198e75CAC48E |
|
||||
|
||||
### Token Bridge
|
||||
|
||||
| Chain Name | Wormhole Chain ID | Network ID | Address |
|
||||
| :-------------------- | :---------------- | :----------- | :------ |
|
||||
| Solana | 1 | mainnet-beta | wormDTUJ6AWPNvk59vGQbDvGJmqbDTdgWgAqcLBCgUb |
|
||||
| Ethereum | 2 | 1 | 0x3ee18B2214AFF97000D974cf647E7C347E8fa585 |
|
||||
| Terra | 3 | columbus-5 | terra10nmmwe8r3g99a9newtqa7a75xfgs2e8z87r2sf |
|
||||
| Binance Smart Chain | 4 | 56 | 0xB6F6D86a8f9879A9c87f643768d9efc38c1Da6E7 |
|
||||
| Polygon | 5 | 137 | 0x5a58505a96D1dbf8dF91cB21B54419FC36e93fdE |
|
||||
| Avalanche (C-Chain) | 6 | 43114 | 0x0e082F06FF657D94310cB8cE8B0D9a04541d8052 |
|
||||
| Oasis (Emerald) | 7 | 4262 | 0xfE8cD454b4A1CA468B57D79c0cc77Ef5B6f64585 |
|
||||
| Aurora | 9 | 1313161554 | 0x51b5123a7b0F9b2bA265f9c4C8de7D78D52f510F |
|
||||
| Fantom | 10 | 250 | 0x7C9Fc5741288cDFdD83CeB07f3ea7e22618D79D2 |
|
||||
| Karura | 11 | 686 | 0xae9d7fe007b3327AA64A32824Aaac52C42a6E624 |
|
||||
| Acala | 12 | 787 | 0xae9d7fe007b3327AA64A32824Aaac52C42a6E624 |
|
||||
| Klaytn | 13 | 8217 | 0x5b08ac39EAED75c0439FC750d9FE7E1F9dD0193F |
|
||||
| Celo | 14 | 42220 | 0x796Dff6D74F3E27060B71255Fe517BFb23C93eed |
|
||||
|
||||
### NFT Bridge
|
||||
|
||||
| Chain Name | Wormhole Chain ID | Network ID | Address |
|
||||
| :-------------------- | :---------------- | :----------- | :------ |
|
||||
| Solana | 1 | mainnet-beta | WnFt12ZrnzZrFZkt2xsNsaNWoQribnuQ5B5FrDbwDhD |
|
||||
| Ethereum | 2 | 1 | 0x6FFd7EdE62328b3Af38FCD61461Bbfc52F5651fE |
|
||||
| Binance Smart Chain | 4 | 56 | 0x5a58505a96D1dbf8dF91cB21B54419FC36e93fdE |
|
||||
| Polygon | 5 | 137 | 0x90BBd86a6Fe93D3bc3ed6335935447E75fAb7fCf |
|
||||
| Avalanche (C-Chain) | 6 | 43114 | 0xf7B6737Ca9c4e08aE573F75A97B73D7a813f5De5 |
|
||||
| Oasis (Emerald) | 7 | 4262 | 0x04952D522Ff217f40B5Ef3cbF659EcA7b952a6c1 |
|
||||
| Aurora | 9 | 1313161554 | 0x6dcC0484472523ed9Cdc017F711Bcbf909789284 |
|
||||
| Fantom | 10 | 250 | 0xA9c7119aBDa80d4a4E0C06C8F4d8cF5893234535 |
|
||||
| Karura | 11 | 686 | 0xb91e3638F82A1fACb28690b37e3aAE45d2c33808 |
|
||||
| Acala | 12 | 787 | 0xb91e3638F82A1fACb28690b37e3aAE45d2c33808 |
|
||||
| Klaytn | 13 | 8217 | 0x3c3c561757BAa0b78c5C025CdEAa4ee24C1dFfEf |
|
||||
| Celo | 14 | 42220 | 0xA6A377d75ca5c9052c9a77ED1e865Cc25Bd97bf3 |
|
||||
|
||||
## Testnet
|
||||
|
||||
### Core Bridge
|
||||
|
||||
| Chain Name | Wormhole Chain ID | Network ID | Address |
|
||||
| :--------------------- | :---------------- | :----------- | :------ |
|
||||
| Solana | 1 | devnet | 3u8hJUVTA4jH1wYAyUur7FFZVQ8H635K3tSHHF4ssjQ5 |
|
||||
| Ethereum (Goerli) | 2 | 5 | 0x706abc4E45D419950511e474C7B9Ed348A4a716c |
|
||||
| Ethereum (Ropsten) | 10001 | 3 | 0x210c5F5e2AF958B4defFe715Dc621b7a3BA888c5 |
|
||||
| Terra | 3 | bombay-12 | terra1pd65m0q9tl3v8znnz5f5ltsfegyzah7g42cx5v |
|
||||
| Binance Smart Chain | 4 | 97 | 0x68605AD7b15c732a30b1BbC62BE8F2A509D74b4D |
|
||||
| Polygon (Mumbai) | 5 | 80001 | 0x0CBE91CF822c73C2315FB05100C2F714765d5c20 |
|
||||
| Avalanche (Fuji) | 6 | 43113 | 0x7bbcE28e64B3F8b84d876Ab298393c38ad7aac4C |
|
||||
| Oasis (Emerald Testnet)| 7 | 42261 | 0xc1C338397ffA53a2Eb12A7038b4eeb34791F8aCb |
|
||||
| Algorand (Testnet) | 8 | | 86525623 |
|
||||
| Aurora | 9 | 1313161555 | 0xBd07292de7b505a4E803CEe286184f7Acf908F5e |
|
||||
| Fantom | 10 | 4002 | 0x1BB3B4119b7BA9dfad76B0545fb3F531383c3bB7 |
|
||||
| Karura | 11 | 686 | 0xE4eacc10990ba3308DdCC72d985f2a27D20c7d03 |
|
||||
| Acala | 12 | 787 | 0x4377B49d559c0a9466477195C6AdC3D433e265c0 |
|
||||
| Klaytn | 13 | 1001 | 0x1830CC6eE66c84D2F177B94D544967c774E624cA |
|
||||
| Celo | 14 | 44787 | 0x88505117CA88e7dd2eC6EA1E13f0948db2D50D56 |
|
||||
|
||||
### Token Bridge
|
||||
|
||||
| Chain Name | Wormhole Chain ID | Network ID | Address |
|
||||
| :--------------------- | :---------------- | :----------- | :------ |
|
||||
| Solana | 1 | devnet | DZnkkTmCiFWfYTfT41X3Rd1kDgozqzxWaHqsw6W4x2oe |
|
||||
| Ethereum (Goerli) | 2 | 5 | 0xF890982f9310df57d00f659cf4fd87e65adEd8d7 |
|
||||
| Ethereum (Ropsten) | 10001 | 3 | 0xF174F9A837536C449321df1Ca093Bb96948D5386 |
|
||||
| Terra | 3 | bombay-12 | terra1pseddrv0yfsn76u4zxrjmtf45kdlmalswdv39a |
|
||||
| Binance Smart Chain | 4 | 97 | 0x9dcF9D205C9De35334D646BeE44b2D2859712A09 |
|
||||
| Polygon (Mumbai) | 5 | 80001 | 0x377D55a7928c046E18eEbb61977e714d2a76472a |
|
||||
| Avalanche (Fuji) | 6 | 43113 | 0x61E44E506Ca5659E6c0bba9b678586fA2d729756 |
|
||||
| Oasis (Emerald Testnet)| 7 | 42261 | 0x88d8004A9BdbfD9D28090A02010C19897a29605c |
|
||||
| Algorand (Testnet) | 8 | | 86525641 |
|
||||
| Aurora | 9 | 1313161555 | 0xD05eD3ad637b890D68a854d607eEAF11aF456fba |
|
||||
| Fantom | 10 | 4002 | 0x599CEa2204B4FaECd584Ab1F2b6aCA137a0afbE8 |
|
||||
| Karura | 11 | 686 | 0xd11De1f930eA1F7Dd0290Fe3a2e35b9C91AEFb37 |
|
||||
| Acala | 12 | 787 | 0xebA00cbe08992EdD08ed7793E07ad6063c807004 |
|
||||
| Klaytn | 13 | 1001 | 0xC7A13BE098720840dEa132D860fDfa030884b09A |
|
||||
| Celo | 14 | 44787 | 0x05ca6037eC51F8b712eD2E6Fa72219FEaE74E153 |
|
||||
|
||||
### NFT Bridge
|
||||
|
||||
| Chain Name | Wormhole Chain ID | Network ID | Address |
|
||||
| :--------------------- | :---------------- | :----------- | :------ |
|
||||
| Solana | 1 | devnet | 2rHhojZ7hpu1zA91nvZmT8TqWWvMcKmmNBCr2mKTtMq4 |
|
||||
| Ethereum (Goerli) | 2 | 5 | 0xD8E4C2DbDd2e2bd8F1336EA691dBFF6952B1a6eB |
|
||||
| Ethereum (Ropsten) | 10001 | 3 | 0x2b048Da40f69c8dc386a56705915f8E966fe1eba |
|
||||
| Binance Smart Chain | 4 | 97 | 0xcD16E5613EF35599dc82B24Cb45B5A93D779f1EE |
|
||||
| Polygon (Mumbai) | 5 | 80001 | 0x51a02d0dcb5e52F5b92bdAA38FA013C91c7309A9 |
|
||||
| Avalanche (Fuji) | 6 | 43113 | 0xD601BAf2EEE3C028344471684F6b27E789D9075D |
|
||||
| Oasis (Emerald Testnet)| 7 | 42261 | 0xC5c25B41AB0b797571620F5204Afa116A44c0ebA |
|
||||
| Aurora | 9 | 1313161555 | 0x8F399607E9BA2405D87F5f3e1B78D950b44b2e24 |
|
||||
| Fantom | 10 | 4002 | 0x63eD9318628D26BdCB15df58B53BB27231D1B227 |
|
||||
| Karura | 11 | 686 | 0x0A693c2D594292B6Eb89Cb50EFe4B0b63Dd2760D |
|
||||
| Acala | 12 | 787 | 0x96f1335e0AcAB3cfd9899B30b2374e25a2148a6E |
|
||||
| Klaytn | 13 | 1001 | 0x94c994fC51c13101062958b567e743f1a04432dE |
|
||||
| Celo | 14 | 44787 | 0xaCD8190F647a31E56A656748bC30F69259f245Db |
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
# Repository
|
||||
Wormhole core repository is [here](https://github.com/certusone/wormhole).
|
||||
|
||||
|
||||
|
||||
# Design Documents
|
||||
|
||||
Wormhole's components are designed via specifications that can be found [here](https://github.com/certusone/wormhole/tree/dev.v2/whitepapers). These outline the reasoning behind design decisions and details specifics in more technical depth.
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
# RPC Nodes
|
||||
|
||||
These RPC nodes are maintained by the Guardians to help fetch VAAs and query the Wormhole network.
|
||||
|
||||
|
||||
## Mainnet Guardian RPC
|
||||
```
|
||||
https://wormhole-v2-mainnet-api.certus.one
|
||||
https://wormhole.inotel.ro
|
||||
https://wormhole-v2-mainnet-api.mcf.rocks
|
||||
https://wormhole-v2-mainnet-api.chainlayer.network
|
||||
https://wormhole-v2-mainnet-api.staking.fund
|
||||
https://wormhole-v2-mainnet.01node.com
|
||||
```
|
||||
|
||||
## Testnet Guardian RPC
|
||||
```
|
||||
https://wormhole-v2-testnet-api.certus.one
|
||||
```
|
||||
|
||||
## Testnet Guardian Public Key
|
||||
```
|
||||
0x13947Bd48b18E53fdAeEe77F3473391aC727C638
|
||||
```
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
# Tools
|
||||
There's various tools in the Wormhole ecosystem that can help you in developing xDapps.
|
||||
|
||||
# Testnet
|
||||
Wormhole has deployed Core Bridge, Token Bridge, and NFT Bridge contracts on the various testnets of the chains that Wormhole connects to. You can see the deployed addresses [here](./contracts.md). There's only a single guardian that oversees the testnets, so you might get a higher rate of missed VAAs than you will on mainnet.
|
||||
|
||||
# Wormhole Explorer
|
||||
Wormhole Explorer is a tool that will help you parse VAAs after they've been picked up the Guardian network. It's available [here](https://wormholenetwork.com/en/explorer).
|
||||
|
||||
# Testnet Bridge UI
|
||||
If you'd like to try out Portal Bridge on Testnet, there's a UI you can use to attest and transfer tokens for testnet. It's hosted [here](https://certusone.github.io/wormhole).
|
||||
|
||||
# Tilt
|
||||
Tilt is a Kubernetes based tool that runs a copy of every chain along side a guardian node to create a simulated testing environment. To get it setup and test against it, check it out [here](../development/tilt/overview.md).
|
||||
|
||||
# Wormhole SDK
|
||||
The SDK is a set of Javascript tools to help you do Token Bridge transfers, fetch and submit VAAs from one chain to another. You can install it via NPM [here](https://www.npmjs.com/package/@certusone/wormhole-sdk).
|
||||
Loading…
Reference in New Issue