project-serum / serum-dex Goto Github PK

The current pattern of AccountMeta arrays is verbose and error prone (incorrect ordering within the array, forgetting to mark as readonly or writable or signer, etc). We should generate Request structs that just take in the basic Pubkeys and Keypairs needed along with any arguments.

Hi! I'm an engineer from solana. :)

To make long story short, could you update your forked borsh crate to be rebased onto borsh-rs v0.8.1?

We noticed updating serde to v1.0.122 at the solana monorepo would break serum-dex build: https://buildkite.com/solana-labs/solana/builds/38795#a018ae71-7d4c-4dc2-a9a9-fab840bcd3ef/1360-1834. Don't worry. We won't do that soon. This is just maintenance update at our side. :)

If there is better way for you like bumping solana-program and/or spl, please let us know.

Details

Well, there are various crates involved.

Firstly, solana-program crates use serde. And serde v1.0.122 now depends on syn >= v1.0.60 specifically and it broke build of borsh-rs < v0.8.0: near/borsh-rs#2 (this pr should be in borsh-rs v0.8.0)

Then, serum-dex uses both solana-program and borsh-rs, which would be unable to build with conflicting versions.

These changes seems to be introduced by this pr: #51

Also, it seems that you're also pinning syn at forked branch:
https://github.com/project-serum/borsh/blob/90fcdf51f4c0333002a00a2db7367cc672882dc5/borsh-rs/borsh-derive-internal/Cargo.toml#L17

by this commit https://github.com/project-serum/borsh/pull/1/commits/884c56711c732d172f5d65374feff1fb796d4841

It may become unnecessary?

Also, updated borsh-rs isn't pinning syn it seems: https://github.com/near/borsh-rs/blob/3dddc6d7af2e66bf4f5947c0187a9d1f7dae6888/borsh-schema-derive-internal/Cargo.toml#L16

So, I'm thinking you can just update borsh-rs to v0.8.1, considering it's not pinning syn version: https://crates.io/crates/borsh-derive-internal/0.8.1

(A bit odd thing is that it seems spl succeeded to build with syn v1.0.60 and it seems pinning syn isn't working in your repository for some reason...)

CC: @armaniferrante (mentioning based on relevant commit's author info, nice to meet you!), @mvines (my dependable rust dependency-hell solving expert.)

Hi, trying some script, forwarding future automated trading with pyserum, and i was testing about some of the functions.
and having issues trying to settle funds and cancelling orders. Resolved the cancelling and here is the problem: About settle, i couldn't do so, because, apparently error on the base_wallet, in the settle request:

settl = market.settle_funds(
        owner=payer,
        open_orders=open_orders_account[0],
        base_wallet='De4FSZ2KakxHowj1TfVxos3tjoimbtrTtceoNasMwetW',
        quote_wallet='Hrr32WnYSqikhRRjHUpVTDarTApKUPu3fgdozg9PYrcZ'
    )

i had put my owner_wallet, and that's why it didn't worked. But i put by error the base_vault then no more error, i thought that's it, Yeah! but the amount didn't return in the token account... How that's possible? making a settle could result in lost of fund? it's not big deal, i was testing and the amount wasn't so big (0.001BTC), but hope it won't happen with big amount? here's the settled signature:
https://explorer.solana.com/tx/8hhv4WuZxua2PKRtZmBBvhYDK8XQRgswV21CqpYownkJv3ivVkWD5adzAJYra1kUnuguTyUk95XGX2vgNV7Mbee
what's the base vault? and is it possible to make unpossible settle transfert, somewhere else than owner token_wallet?

The request queue is no longer used however it's still passed into accounts. This is problematic because it increases the transaction size, unnecessarily, which easily becomes a problem when one starts composing with the DEX.

Open orders accounts are implicitly initialized when first used. It would be convenient to have an explicit instruction for this, so that PDAs can set themselves as the owner without having to make a trade.

Hi I am trying to build the DEX. I ran the following:

./do.sh build dex

However it's telling me:

$ ./do.sh build dex
Building /home/wangge/serum-dex/dex
+ [[ -n '' ]]
+ cargo install xargo
    Updating crates.io index
     Ignored package `xargo v0.3.22` is already installed, use --force to override
+ xargo --version
+ rustc --print sysroot
/home/wangge/.rustup/toolchains/stable-x86_64-unknown-linux-gnu
+ set +e
+ rustup toolchain uninstall bpf
info: no toolchain installed for 'bpf'
+ set -e
+ rustup toolchain link bpf rust-bpf
error: not a directory: 'rust-bpf/lib'

Any idea why?

It's easy for GUIs to create multiple open orders accounts for a given user by accident. This can cause users to have unsettled balances they aren't aware of, if the GUI doesn't display all open orders accounts. Using a PDA solves this.

We should consider building into the staking program an "auto deprecate" feature.

On initialization, we can give the registrar a unix timestamp specifying when staking halts. If anyone tries to stake or switch nodes past that date, the program can return an error, requiring users to upgrade to the new version.

Is there any js-sdk of serum coin available for transaction?

I want to integrate it into OPOLO hardware wallet.

Currently, a Member can claim any reward in the reward event queue as long as it's at a position greater than the Member account's cursor (assuming they were staked in the right pool at the right time).

We should add an additional safety check preventing people from skipping unclaimed rewards.

cargo build-bpf is the new, more modern way to build programs that is much more developer friendly.

Futhermore, according to @dafyddd, switching results in

• a 30% smaller binary
• compute cost of cancel and new order functions being about 20% lower

This will be useful for people compiling their own programs that depend on serum dex

We should explore compiling the various clients in the repo to WASM, so that we can get JS clients for free and iterate faster. Will require forking Solana.

Currently this is being done in the safe crate via #![cfg_attr(feature = "strict", deny(warnings))].

However, Solana programs are built via bin/bpf_sdk/rust/build.sh, which passes in features. So we'd have to modify that script if we want -Werror to be conditional. Alternatively we can make it unconditional (and then run the risk of the build breaking due to rust changes).

Given that Solana is pinning rust versions, I wouldn't be against unconditional warnings as errors for Solana programs.

To Initialize a pool one must send an InitializePoolRequest.

This request can carry custom data (pub custom_data: Vec<u8> inside InitializePoolRequest) but this data is currently not made available to the initialize_pool method in pool.rs.

Describe how registry reward vendor expiry works

Summary

When trading a derivative, for example a perpetual swap, a user can not use their normal spot trading account, they would need to use a margin trading account. Currently, within Serum there is no way to limit what sort of accounts can trade in which markets.

Ideally there would be a way to tell a market to only accept trades from a certain account type.

I haven't looked at the code behind serum so not sure what this would entail.

There should be an instruction for one to close dead markets to retrieve the rent exemption SOL.

A u64 used for the nonce/bump seed, rather than a u8. This is inconsistent with the rest of the solana tooling, creating confusion when integrating with the dex. See https://github.com/project-serum/serum-dex/blob/master/dex/src/state.rs#L1154.

Build is passing even though we get an error.

https://travis-ci.com/github/project-serum/serum-dex/jobs/397072801#L1779

Tracking issue for https://github.com/project-serum/rfcs/blob/master/text/0001-registry.md

Errors reported when running the README for the first time on master.

Error on whole-shebang:

Listing 3qWUqFkyUo5doWyRZ8iKoGkkuJ3rZ71GDFSSy1bznbHL ...
Market keys: MarketPubkeys {
    market: 3qWUqFkyUo5doWyRZ8iKoGkkuJ3rZ71GDFSSy1bznbHL,
    req_q: 8Y1TF5B5vbJgcUsCUxQGgpzyY4Axtio3f4sSpFbarZX6,
    event_q: HP9GBesqD3wcHjAbfDdP2aepdS56ZKnds6ajom7K1hYF,
    bids: BNkcXwfiEjnRm4nfCYmAFRbqTABvjPKLQEAY2BhSvJN4,
    asks: 7fCtDUkjy9TQFBN8KF6RBRmbaXr4fQ4yyiu2nDrD6yAZ,
    coin_vault: FjDjivsBHMpfKCAz9zkd2P9gMqLa8yR8zDxkVqNxuzxY,
    pc_vault: 779ht7oxy1Ma7aG6RdFvJbtApedWPZQY78iq4sFxhxWg,
    vault_signer_key: 8sn6wZCz3ouoreNVsgiGgHPRt116VN29eJaAzj9mji5N,
}
Minting coin...
Minted CaneHWp3ur7jRoTttgJhvuoTCGP5ZkuH4193MTb1pwzA
Minting price currency...
Minted EhZJHf2jz6LzKyM7JcZFic3q2MhCqUtGhuWbuU3wnYfs
Placing bid...
![Screenshot from 2020-08-03 14-16-05](https://user-images.githubusercontent.com/6990215/95120742-d9c7a180-0702-11eb-8a67-96fb6eae194f.png)

Error: Error processing Instruction 1: custom program error: 0xb9f0002
Caused by:
    Error processing Instruction 1: custom program error: 0xb9f0002

Unit tests:

test tests::test_new_order ... FAILED

User is running macOS.

The work in #32 introduces a rewards proxy program for cranks. We should add a CLI option to use this to the crank client uility.

There should be the ability to close an open orders account so that the trader can get the rent exemption deposit back.

Saw an issue made in the serum-ts that appears to be more related to the functionality of the serum dex, than the ts library.

project-serum/serum-ts#61

I've gotten it to work using WSL2 with some workarounds, but we should document that setup.

We can use the docker image here https://hub.docker.com/r/projectserum/build to build the dex so that the on chain binary can be verified. The artifacts should be built and published by CI on each release, as is done here, for example https://github.com/project-serum/multisig/releases.

We'll have "authority" keys for both testing and governing the first versions of various programs, e.g., registry, rewards, and lockups that will allow us to perform a priviledged set of instructions.

We should list these programs, the authority keys, and who owns them in clear language somewhere. Once these "authority" keys are transferred to governance programs (or locked out by setting to the zero address, for example), we should update these lists.

There's now more than just the dex in the repo. We should move the current README into the dex crate and update the main readme to describe the entire monorepo.

Tracking issue for https://docs.google.com/document/d/1lmMZRKkxMFOtGOEZOFEKYL7syqv-4QT87F0o55fc35Y/edit

Probably doesn't need to be in the top level dir, as it's only used by the various CLI related crates.

Now that the BPF compiler is willing to emit unaligned accesses, we should consider structuring the state accessor code to not depend on the alignment of the account data buffer. This would make it possible to library-ize the state-manipulation code in a portable way, for use by clients and BPF Loader 2 programs.

Hi, as I potentially intend to use/extend the pool program, I would like to know how the testing has been performed. I see a few simple unit tests in the context.rs file and that's it. Is there any integration tests? Was there end to end testing? Thank you
cc @garywang @sconybeare

Describe in plain english what it is and what it does.

The --coin-wallet and --pc-wallet accounts are required by both the Crank CLI and the DEX to be passed in, but aren't actually used. We should remove this requirement. https://github.com/project-serum/serum-dex/blob/master/crank/src/lib.rs#L114

Currently, crank transactions are required to be signed by the node leader. We should add the ability to whitelist a crank key that is responsible for transaction payments, so that the node leader's key can always be in a trusted environment (i.e. never on the crank server).

Not sure how to pass public keys to crank via the command line.

ProgramID after deploy:

{"programId":"GoQSkAkmupP3ZndREdw84KuQHUJiziR35MJGvQQE5gW3"}

Running:

cargo run -- l whole-shebang payer=~/.config/solana/id.json dex-program-id=GoQSkAkmupP3ZndREdw84KuQHUJiziR35MJGvQQE5gW3

Error:

error: Invalid value for '<dex-program-id>': Invalid Base58 string

sol address:7ewn8oj7MWyhZE5qFux1npzUnuT4XCVvBvYiMHehYvBb
usdt address:8pkzuX9GjrgEFuX4JXQeV4hcSjwTba59yC92vSfbz45H
fida address:4BCnuuQXHXEMiUVYYA7mw2Jc5AyX5q1FcTRDmvnV9uDR

i submit an order https://explorer.solana.com/tx/522X9qN66UMbSoLk5Sry9iRcm9zFFoaR1M34qysJSedtCQ5893ofNhxx61uaqnRxj4b8cadfXH4YEM1BV1Bd3WKP , then i've cancelled it twice , not sure why.. https://explorer.solana.com/tx/54GUkmszRxT9g8T9GFL2PZRyi8Z6PDKzmT5STkVVbGcHoQRgRNC6HUeChTuggKDdmFsn1GM6WLHrbx3MeQJVAHfZ and https://explorer.solana.com/tx/46XJr3zDs94tmDNgjXHhQJTYFQfPnjyKKrzrRtYcWYNJ9672zEiv9XxZZsmuHj2h3N1fnNVfMA5po8K1QLe1zhvb

then not sure what i did there when i've tried to settle_my funds https://explorer.solana.com/tx/2ph3m68QKaxjyyk2SmBQ2m2j6XF7ksYjMiz9hVo9eo5toKhPopQRj8XT6AA8AdPUXBNEo39cy5zf91WHYC8i2WMS

open_orders_account = market.find_open_orders_accounts_for_owner(owner_address=PublicKey('7ewn8oj7MWyhZE5qFux1npzUnuT4XCVvBvYiMHehYvBb'))
but when i do now settle_funds it sends me 0 usdt back all the time
https://explorer.solana.com/tx/36Rca4VQQe7dodh2VTavXRTPJZGQuknhc4wRt4ST2s8GgQijbFJKwmoDsxgBJnHYrutKQzzCuQtuRc41mfPzUSeZ and https://explorer.solana.com/tx/4gJyqXLH7Xr4XcfwsTjgbjDbFBasHhQjaPjBwkxAk8Cd9hU92xqUHgw2sbRGcP3KonCrFu3PFADF6CoE5PYLHFa4

please dm me on dicord cryptoguy100786#0098

how to get my usdt from of https://explorer.solana.com/address/Dygr7hmVgydf6Cs4CF34EbXbD8xhJJVMXjvYJCR7LqmM ? thanks

I'm working localnet . I have this error.
failed to get token accounts owned by account acSUiwT9cCe4hfaYNATdodj8iJJ3bvmWZyeTBNQmD8S: Invalid param: could not find mint

acSUiwT9cCe4hfaYNATdodj8iJJ3bvmWZyeTBNQmD8S = my Solletio solana address

This would be useful for programs composing with the DEX that don't want to create an open orders account, for example, a user that wants to do a one time swap for a wrapped bridge token to a canonical token (e.g. wrapped wormhole srm to srm).

Currently a --pid is required for using these CLIs.

Once we deploy to mainnet, these parameters should be optional and, if not provided, fallback to the deployed program addresses.

Disabled because the cache was stale, causing this error.

error[E0460]: found possibly newer version of crate `std` which `byteorder` depends on
  --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/bincode-1.3.1/src/lib.rs:32:1
   |
32 | extern crate byteorder;
   | ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: perhaps that crate needs to be recompiled?
   = note: the following crate versions were found:
           crate `std`: /workdir/bin/bpf-sdk/dependencies/xargo/lib/rustlib/bpfel-unknown-unknown/lib/libstd-7d02929b0b6663b3.rlib
           crate `std`: /workdir/bin/bpf-sdk/dependencies/xargo/lib/rustlib/bpfel-unknown-unknown/lib/libstd-7d02929b0b6663b3.rmeta
           crate `byteorder`: /workdir/dex/target/bpfel-unknown-unknown/release/deps/libbyteorder-3b0bb64b1ef60352.rmeta
error: aborting due to previous error
error: could not compile `bincode`.

Confusion around settlement is probably the number one customer support question that comes constantly comes up. Removing the need to settle would be a huge UX win.

As previously mentioned by @sconybeare,

• Settlement can be removed from takes easily
• Provides will be more work, since one has to handle the case where a user deletes a token account, in which case the program will have to fallback to a settlement feature

As discussed with @sconybeare, we should change the whitelist layout to be something like

#[repr(packed])
struct Whitelist {
  header: [u8; HEADER_BYTES];
  items: [[u8; ITEM_LEN]; NUM_ITEMS];
}

Stake rewards cease to be distributed once the total node-entity stake drops below a threshold, activating a countdown where all stakers associated with the entity must withdraw their stake.

We should provide a service that monitors stake amounts and automatically withdraws on behalf of a staker--for a fee. The registry program already supports this functionality.

I tried to buy SOL/USDC or RAY/USDC, HNT/USDC and everytimes I got this error message:

Error placing order
Timed out awaiting confirmation on transaction

I tried on https://dex.projectserum.com/ and I tried on different dex websites as well