certusone
/
wormhole
mirror of https://github.com/certusone/wormhole.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Remove reclaim mechanism from docs

This commit is contained in:
Leo 2020-08-04 17:10:17 +02:00
parent f06c4fc50d
commit d81d916b5e
2 changed files with 3 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/protocol.md
View File

@ -1,7 +1,7 @@
# Wormhole Protocol
The Wormhole protocol is a way of transferring assets between a **root chain** and multiple **foreign chains**.
Therefor it makes use of decentralized oracles called **guardians** to relay transfer information about token transfers
It makes use of decentralized oracles called **guardians** to relay transfer information about token transfers
between the chains.
## The role of guardians
@ -118,10 +118,8 @@ For transfers we implement a Schnorr-Threshold signature schema based on the imp
We'll create a portable "action blob" with a threshold signature to allow anyone to relay action approvals
between chains. We call this structure: **VAA** (Verifiable Action Approval).
A validator action approval leads to information symmetry i.e. if the validators have submitted a VAA to a token lockup
on Solana, this VAA can be used to unlock the tokens on the specified foreign chain, it also proves to the Solana chain
that the lockup is not refundable as it can provably be claimed (as long as safety guarantees are not broken and except
for the case of a guardian set change which is discussed later).
A validator action approval guarantees eventual consistency across chains - if the validators have submitted a VAA to a token lockup
on Solana, this VAA can be used to unlock the tokens on the specified foreign chain.
While for the above mentioned transfers from Solana => foreign chain we use Solana for data availability of the VAAs,
in the other direction data availability i.e. the guardians posting the VAA on the foreign chain (where the transfer

41
docs/solana_program.md
View File

@ -196,44 +196,3 @@ This account is an instance of `spl-token/Mint` tracks a wrapped asset on the So
This account is an instance of `spl-token/TokenAccount` and holds spl tokens in custody that have been transferred to a
foreign chain.
## Archive
### Reclaim mechanism
**Options:**
| Parameter | Description |
| ------------------------------ | --------------------------------------------------------------------------- |
| RELEASE_WRAPPED_TIMEOUT_PERIOD | The period in which enough votes need to be cast for an asset to be minted. |
Reclaim calls were intended to allow users to reclaim tokens if no VAA was provided in time. This would protect a user
against censorship attacks from guardians.
However this opens a window for race conditions where a VAA would be delayed and the user would frontrun that VAA with
a Reclaim.
#### Reclaim
Reclaim tokens that did not receive enough VAAs on the `proposal` within the `SIGN_PERIOD` to finish the transfer.
`claimant` will get back the `locked_token` previously locked via `ITransferOut`.
| Index | Name | Type | signer | writeable | empty | derived |
| ----- | ------------ | ------------------- | ------ | --------- | ----- | ------- |
| 0 | claimant | TokenAccount | | ✅ | | |
| 1 | bridge | BridgeConfig | | | | |
| 2 | proposal | TransferOutProposal | | ✅ | | ✅ |
| 3 | locked_token | WrappedAsset | | | | ✅ |
#### ReclaimNative
Reclaim tokens that did not receive enough VAAs on the `proposal` within the `SIGN_PERIOD` to finish the transfer.
`claimant` will get back the `locked_token` previously locked via `ITransferOutNative` from the `custody_account`.
| Index | Name | Type | signer | writeable | empty | derived |
| ----- | --------------- | ------------------- | ------ | --------- | ----- | ------- |
| 0 | claimant | TokenAccount | | ✅ | | |
| 1 | bridge | BridgeConfig | | | | |
| 2 | proposal | TransferOutProposal | | ✅ | | ✅ |
| 3 | locked_token | Mint | | | | |
| 4 | custody_account | Mint | | ✅ | | ✅ |