mirror of
https://github.com/serai-dex/serai.git
synced 2025-12-08 04:09:23 +00:00
Tokens pallet (#243)
* Use Monero-compatible additional TX keys This still sends a fingerprinting flare up if you send to a subaddress which needs to be fixed. Despite that, Monero no should no longer fail to scan TXs from monero-serai regarding additional keys. Previously it failed becuase we supplied one key as THE key, and n-1 as additional. Monero expects n for additional. This does correctly select when to use THE key versus when to use the additional key when sending. That removes the ability for recipients to fingerprint monero-serai by receiving to a standard address yet needing to use an additional key. * Add tokens_primitives Moves OutInstruction from in-instructions. Turns Destination into OutInstruction. * Correct in-instructions DispatchClass * Add initial tokens pallet * Don't allow pallet addresses to equal identity * Add support for InInstruction::transfer Requires a cargo update due to modifications made to serai-dex/substrate. Successfully mints a token to a SeraiAddress. * Bind InInstructions to an amount * Add a call filter to the runtime Prevents worrying about calls to the assets pallet/generally tightens things up. * Restore Destination It was meged into OutInstruction, yet it didn't make sense for OutInstruction to contain a SeraiAddress. Also deletes the excessively dated Scenarios doc. * Split PublicKey/SeraiAddress Lets us define a custom Display/ToString for SeraiAddress. Also resolves an oddity where PublicKey would be encoded as String, not [u8; 32]. * Test burning tokens/retrieving OutInstructions Modularizes processor_coinUpdates into a shared testing utility. * Misc lint * Don't use PolkadotExtrinsicParams
This commit is contained in:
Luke Parker
GitHub
@@ -40,10 +40,10 @@ Serai token. If an Application Call, the encoded call will be executed.
|
||||
|
||||
### Refundable In Instruction
|
||||
|
||||
- `origin` (Option\<ExternalAddress>): Address, from the network of origin,
|
||||
which sent coins in.
|
||||
- `instruction` (InInstruction): The action to perform with the incoming
|
||||
coins.
|
||||
- `origin` (Option\<ExternalAddress>): Address, from the network of
|
||||
origin, which sent coins in.
|
||||
- `instruction` (InInstruction): The action to perform with the
|
||||
incoming coins.
|
||||
|
||||
Networks may automatically provide `origin`. If they do, the instruction may
|
||||
still provide `origin`, overriding the automatically provided value.
|
||||
@@ -51,19 +51,18 @@ still provide `origin`, overriding the automatically provided value.
|
||||
If the instruction fails, coins are scheduled to be returned to `origin`,
|
||||
if provided.
|
||||
|
||||
### Destination
|
||||
|
||||
Destination is an enum of SeraiAddress and ExternalAddress.
|
||||
|
||||
### Out Instruction
|
||||
|
||||
- `destination` (Destination): Address to receive coins to.
|
||||
- `data` (Option\<Data>): The data to call the destination with.
|
||||
- `address` (ExternalAddress): Address to transfer the coins included with
|
||||
this instruction to.
|
||||
- `data` (Option<Data>): Data to include when transferring coins.
|
||||
|
||||
Transfer the coins included with this instruction to the specified address with
|
||||
the specified data. No validation of external addresses/data is performed
|
||||
on-chain. If data is specified for a chain not supporting data, it is silently
|
||||
dropped.
|
||||
No validation of external addresses/data is performed on-chain. If data is
|
||||
specified for a chain not supporting data, it is silently dropped.
|
||||
|
||||
### Destination
|
||||
|
||||
Destination is an enum of SeraiAddress and OutInstruction.
|
||||
|
||||
### Shorthand
|
||||
|
||||
@@ -80,7 +79,7 @@ covered by Shorthand.
|
||||
- `origin` (Option\<ExternalAddress>): Refundable In Instruction's `origin`.
|
||||
- `coin` (Coin): Coin to swap funds for.
|
||||
- `minimum` (Amount): Minimum amount of `coin` to receive.
|
||||
- `out` (Out Instruction): Final destination for funds.
|
||||
- `out` (Destination): Final destination for funds.
|
||||
|
||||
which expands to:
|
||||
|
||||
|
||||
@@ -1,98 +0,0 @@
|
||||
# Scenarios
|
||||
|
||||
### Pong
|
||||
|
||||
Pong has Serai receive funds, just to return them. It's a demonstration of the
|
||||
in/out flow.
|
||||
|
||||
```
|
||||
Shorthand::Raw(
|
||||
In Instruction {
|
||||
target: Incoming Asset Contract,
|
||||
data: native_transfer(Incoming Asset Sender)
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
### Wrap
|
||||
|
||||
Wrap wraps an asset from a connected chain into a Serai Asset, making it usable
|
||||
with applications on Serai, such as Serai DEX.
|
||||
|
||||
```
|
||||
Shorthand::Raw(
|
||||
In Instruction {
|
||||
target: Serai Address
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
### Swap SRI to Bitcoin
|
||||
|
||||
For a SRI to Bitcoin swap, a SRI holder would perform an
|
||||
[Application Call](../Serai.md#application-calls) to Serai DEX, purchasing
|
||||
seraiBTC. Once they have seraiBTC, they are able to call `native_transfer`,
|
||||
transferring the BTC underlying the seraiBTC to a specified Bitcoin address.
|
||||
|
||||
### Swap Bitcoin to Monero
|
||||
|
||||
For a Bitcoin to Monero swap, the following Shorthand would be used.
|
||||
|
||||
```
|
||||
Shorthand::Swap {
|
||||
coin: Monero,
|
||||
minimum: Minimum Monero from Swap,
|
||||
out: Monero Address
|
||||
}
|
||||
```
|
||||
|
||||
This Shorthand is expected to generally take:
|
||||
|
||||
- 1 byte to identify as Swap.
|
||||
- 1 byte to not override `origin`.
|
||||
- 1 byte for `coin`.
|
||||
- 4 bytes for `minimum`.
|
||||
- 1 byte for `out`'s `destination`'s ordinal byte.
|
||||
- 65 bytes for `out`'s `destination`'s address.
|
||||
- 1 byte to not include `data` in `out`.
|
||||
|
||||
Or 74 bytes.
|
||||
|
||||
### Add Liquidity (Fresh)
|
||||
|
||||
For a user who has never used Serai before, they have three requirements to add
|
||||
liquidity:
|
||||
|
||||
- Minting the Serai asset they wish to add liquidity for
|
||||
- Acquiring Serai, as liquidity is symmetric
|
||||
- Acquiring Serai for gas fees
|
||||
|
||||
The Add Liquidity Shorthand enables all three of these actions, and actually
|
||||
adding the liquidity, in just one transaction from a connected network.
|
||||
|
||||
```
|
||||
Shorthand::AddLiquidity {
|
||||
minimum: Minimum SRI from Swap,
|
||||
gas: Amount of SRI to keep for gas
|
||||
address: Serai address for the liquidity tokens and gas
|
||||
}
|
||||
```
|
||||
|
||||
For adding liquidity from Bitcoin, this Shorthand is expected to generally take:
|
||||
|
||||
- 1 byte to identify as Add Liquidity.
|
||||
- 1 byte to not override `origin`.
|
||||
- 5 bytes for `minimum`.
|
||||
- 4 bytes for `gas`.
|
||||
- 32 bytes for `address`.
|
||||
|
||||
Or 43 bytes.
|
||||
|
||||
### Add Liquidity (SRI Holder)
|
||||
|
||||
For a user who already has SRI, they solely need to have the asset they wish to
|
||||
add liquidity for via their SRI. They can either purchase it from Serai DEX, or
|
||||
wrap it as detailed above.
|
||||
|
||||
Once they have both their SRI and the asset they wish to provide liquidity for,
|
||||
they would use a Serai transaction to call the DEX, adding the liquidity.
|
||||
Reference in New Issue
Block a user