As far as simple solution goes: paritytech/substrate#7685

some examples to look at:
https://github.com/jimmychu0807/substrate-offchain-pricefetch/blob/ceb7b5994b480a19f2bc5068860a26068d4f8ef3/substrate/pallets/price-fetch/src/lib.rs#L301

Better solution would probably be to add method to "Price" to serialize from f64 or any other type we get from deserializing JSON

Dependabot couldn't parse the Cargo.toml found at /runtime/Cargo.toml.

The error Dependabot encountered was:

Dependabot::DependencyFileNotParseable

View the update logs.

• create and commit chain_spec.json
• run

Use in and out internally to be consistent and clear.
Keep sell and buy only for user facing functions.

• amm
• exchange
• wasm https://github.com/galacticcouncil/HydraDX-wasm
• math galacticcouncil/HydraDX-math#5

• Make transaction payment currency set configurable in chain_spec
• Allow addition / removal of currencies to this set ( we can start with endowed accounts in the beginning )

Sells/Buys with discounts should go through without the discount if the pair hdx/asset does not exists.

Currently sell and buys returns error "CannotApplyDiscount" and if this sells is part of the matched transactions , it can lead to scenarion where only part of the amount is trade ( directtrade )

info:
polkadot-js/api#2464
AcalaNetwork/Acala#349
polkadot-js/api#2516

blocked by #11

There is hbs template in the .maintain directory which currently does not follow same formatting guidelines.

Currently , the extra weight for the payment is set as follows:

pub const ExtrinsicPaymentExtraWeight: Weight = 307_000_000;
pub const ExtrinsicBaseWeight: Weight = frame_support::weights::constants::ExtrinsicBaseWeight::get() + ExtrinsicPaymentExtraWeight::get();

It would be nice if the ExtrinsicPaymentExtraWeight is taken from the weight information localted in the transaction multi payment pallet.

For example, something like this :

pub const ExtrinsicPaymentExtraWeight: Weight = PaymentModule::weights::swap_currency() as Weight;

However, this is const and it is not as straightforward. It might need little Rust and Substrate magic to get it working.

As in #56

We're planning to distribute our tokens on the Ethereum network so that people can participate early on our upcoming 🐍 Snakenet. Stakers will have limited time to acquire xHDX tokens on Ethereum and after this phase, we'll freeze their balances in order to move them to our chain. This is where this pallet comes to play.

1. Ethereum addresses and their balances have to be imported somehow into the storage
   • up to you, can be solved multiple ways, either runtime upgrade or some sudo extrinsic comes to mind
   • there could be up to 10k addresses
2. Stakers will be able to claim tokens into their HydraDX wallet
   • they have to prove ownership of the Ethereum wallet by signing a message
   • signature will be sent by using extrinsic without fee (we expect them to have no balance)
   • if the signature is valid, claim balance will be cleared and HDX tokens minted to the account

Helpful resources:

claims site https://claims.polkadot.network/

• fe src (?) https://github.com/rmnprkrl/dev-w3fca
• dot allocation tracker contract https://etherscan.io/address/0xb59f67a8bff5d8cd03f6ac17265c550ed8f33907
  • contracts src https://github.com/w3f/polkadot-claims
  • chainspec generator https://github.com/w3f/chainspec-generator
• claims on polkadot network https://polkadot.js.org/apps/#/claims
  • src (including eth message verification) https://github.com/paritytech/polkadot/blob/98ccd02842d6ab22ee1266f90f597c1454f12669/runtime/common/src/claims.rs
• lockdrop by plasm used for KSM issuance
  • https://docs.plasmnet.io/learn/lockdrop

Replace aura with babe and add staking

• remove alice, bob
• remove balances except Intergalactic account
• setup treasury acc
• setup staking
• setup initial keys
• setup initial authorities
• disable balance transfers
• setup initial bootnodes

Dependabot couldn't parse the Cargo.toml found at /runtime/Cargo.toml.

The error Dependabot encountered was:

Dependabot::DependencyFileNotParseable

View the update logs.

Claims will be available after freeze of balances on ETH side. We will then transfer addresses with balances info into our stake-net by runtime upgrade as follows:

STORAGE { (ETHADDR): BALANCE }

Simple UI will connect to the ETH network and HydraDX at the same time. The flow will be following:

1. connect to ETH with metamask || input ETH addres
2. show claimable balance
3. connect to polkadot-js || hydradx
4. sign using metamask || input verification based on sign message generated
5. claim

We'll use Metamask or Infura on the ETH side. Our open node on HydraDX side.

This will trigger ETH address validation on our side and if successful, removes claimable balance from the initial storage, and mint HDX to an address.

Boot up 3 validator nodes + preferably in different providers and different locations.

Boot 2 RPC nodes in different locations.

We'll want to do separate backup node in some serious location / provider.

Let's discard this storage item and use randomly generated hash so that this never overflows.

@orca84 is going to have a look at this.

https://github.com/galacticcouncil/hack.HydraDX-node/blob/694291f74180a4755904a6aa75a3ea4fbfb8ab0e/pallets/exchange/src/lib.rs#L48

The general assumption is that the PoS nodes (can) run offchain workers themselves who publish data (e.g. price feeds) as oracles so that this data can be used on-chain.
To make sure that the offchain workers report their data correctly, we can repurpose the stake they have for validating the blocks themselves. In its simplest iteration such a system could work like this:

1. PoS validators each run an offchain worker that gets and reports data, they include it in a block
2. The blocks are collected over some time (in the order of minutes) and then compared by an on-chain averaging module
3. The averaging module calculates the average (or median or mean or modus) and detects outliers in the data
4. If the outliers are "too far apart" (to be defined), the validator set can execute rules to punish the reporters of this outlying data.
5. If there are different data source families, it could be viable to see each of them as a separate data source so that an error in the off-chain feed does not punish the well-behaving reporters. Instead a warning can be issued if two or more oracle systems differ too much (e.g. DIA reports a price of 1 and another oracle a price of 2, but all DIA nodes are around 1 and all nodes from the other data provider report around 2, nobody in the reporter crowd should be punished)

credit @kaythxbye @martinfridrich @jak-pan

Ideas | PRs welcome

to do:

• Better parsing of oracle data #37
• Include POS in the runtime #39

Upgrade Substrate to the specific git revision: b7712fed2c58a898f7706e16861d7109c8f585a5

And ORML to version 0.3.2

Make sure DOLLARS and HDX/UNIT s are used correctly. We use them interchangeably but in reality 1 dollar should be roughly 10HDX. We'll need to do changes to chainspec too to use HDX/UNIT instead of DOLLARS.

Also token name to HDT -> this might be a bigger effort possibly so I'll keep this as open goal.

Dependabot couldn't parse the Cargo.toml found at /runtime/Cargo.toml.

The error Dependabot encountered was:

Dependabot::DependencyFileNotParseable

View the update logs.

based on #47

Hello everyone, can someone tell me, when buying on a balancer, the transaction was canceled, and a commission of $ 100 was written off, what should I do ??
https://etherscan.io/tx/0x5dffc6afbb9883f6cc033785d502f3ad87575a177b2e19d5f98042f0100da6bf

What I am thinking is that we might want to simplify this sooner than expected since this brings so many questions and probably performance implications. What we wanted to do with tx fees is to burn them instead of accumulating. Similar to EIP1559, but this brings some tokenomics questions which we didn't clear yet.

Right now, we're doing User -> poolSwap (+token,-HDX) -> treasury. We could do just the burn and send on some very basic math really.

Soo... The solution for me is to make it as simple as possible and create new issue that targets this in the omnipool.

Originally posted by @jak-pan in #91 (comment)

#67

Deploy latest POS version to get ready for Balancer

As was mentioned during builder's review session - it would be probably beneficial to spend some effort and investigate use of storage transactions in the exchange pallet's algorithm.

We won't do this as part of the code review changes but will treat this as separate issue ( as this will probably need major refactor ).

• Setup machines that will be running relay chain validator and our collator
• Prepare parachain runtime #11
• Prepare scripts or workflows to inject keys, required metadata and setup for running V1
• Remove Alice,Bob,Charlie... add our own account preferably the one we use on relay chain. Add it to endowed accounts. - @jak-pan << pls test if it works
• Handle parachain security
• Test our local setup on remote

Bonus:

• Get a name for roccoco parachain

we should also strive to be up-to date since heavy development is being done

Per the chain integration guide of SAS, it would be nice to be able to use the minimally exposed RPC to interact with the chain.

Let's check every value for over/underflows before unwrapping everywhere, even if it seems that it cannot fail. Better throw error than crash node. We can optimize later.

https://github.com/galacticcouncil/hack.HydraDX-node/blob/6755e27b0d38369fff6d00009fa7db2e93e0e926/pallets/amm/src/lib.rs#L554

Let's transfer or change this to latest cumulus to be able to connect as a parachain.

Let's have a look at this and decide if we're going to do it before or after merging:
paritytech/cumulus#207

These should be setup so that users cannot abuse the system. We should also have minimal pool creation limit / existential limit because the integer math starts to break at some point. Also we don't want to hold very small pools that are blocking other pools because they are very volatile. (something in range of 100-1000 should be ok for math)

Inspiration here:
https://github.com/galacticcouncil/HydraDX-node/pull/27/files

Some progress was also made in #91