An asset on the stellar network is defined by its asset code (max 12 characters long code) and issuer. For example CNY and Ripplefox (GAREELUB43IRHWEASCFBLKHURCGMHE5IF6XSE7EXDLACYHGRHM43RFOX).
If you have access to a stellar-core instance database, the orderbook is contained in the offers table of the score database. The table schema is the following:
Stellar does not support expiring offers.
Time locks only specify the time window when a Stellar transaction is eligible to be submitted to the network but not it's validity.
Therefore, sending a cancel offer operation after the expiration time is currently the only way of achieving what you want.
Agree with the other answer - looking into internal database is the easiest and most comprehensive way.
But if you don't run your own node, then you could just query horizon:
and then request orderbook for each pair you're interested in
Taking a look at this with the assumption that the attacker controls some validators (as it makes it easier to exploit).
So the way the network deals with transaction ordering is by making it as hard as it can to make it look random:
the apply order sorts by account id xored with the hash of the transaction set
the nomination protocol that gathers ...
When a user creates an order, the corresponding amount of the tokens to sell is automatically locked on her balance (the outstanding amount on orders is listed as selling_liabilities on the account properties). Once another user submits a crossing order, a trade is executed automatically. Both users immediately receive bought tokens on their balances.
The price you set with manageOffer is the maximum price when buying and the minimum price when selling. So it will match the best available price in the orderbook.
If you make an offer that has an immediate counterpart on the orderbook it will behave like a market order (take liquidity).
If you make an offer that doesn't have an immediate counterpart in ...
you need to put it as <MY_WALLET_ADDRESS>*naobtc.com
for amount there is a separate field in every wallet.
But for amount like yours I don't recommend you doing this. Withdrawal fee is 0.0005 BTC as far as I know (UPDATE: looks like withdrawal fee is 0.0002 BTC) , so you just gonna lose your coins. The only way is to exchange it back to ...
I asked the same question earlier.
Jed mentioned that trades are applied in random (actually, pseudo-random) order, and transaction fees do not affect the order in which transactions are applied within the ledger. So larger fees do not prioritize trading operations, preventing Low Latency HFT manipulations.
(Detailed explanation of the tx ...
I suppose this is unlikely. At least there are no APIs to do so directly.
The functionality that you mentioned could cause front-running, which is surely not a good idea for any financial-oriented system.
Moreover, there is no guarantee when a tx would be included in a ledger. Most commonly the txs are included in the next ledger, but sometimes not.
The offer on the orderbook is always a sell offer regardless whether it was created as a result of ManageBuyOffer, ManageSellOffer, or ManagePassiveSellOffer operation. There is no easy way to find out which type of operation resulted in this particular offer creation.
You can analyze all seller account operations where ledger<=last_modified_ledger ...
There is actually no difference to the public network.
Create two assets
Create an intermediary account that holds both of them
Create an offer from that account with manage offer
Make a path payment utilizing that offer to make a payment between any two accounts that have the according trustlines
One alternative could be to integrate with an existing USD anchor (e.g. AnchorUSD). Ecosystem standards like SEP-0024: Interactive Anchor/Wallet Asset Transfer Server (alongside SEP-0010 & SEP-0012) allow you to implement the deposit / withdrawal flow for an anchor within your application. The two resources I would recommend for this are the SEP itself ...
When using the balanced strategy, if a malicious attacker sends some funds to your bot then the bot will set (what might be considered) an incorrect price for the tokens, since it will include these additional funds when computing the relative price of the two tokens.
However, because of this incorrect price, the market should, in theory, correct itself by ...
I'm operating anchor apay.io and half a year ago I was looking at Bifrost if it can be used for my anchor.
Potentially yes, but:
it requires some code changes
you would still need to implement withdrawals, because Bifrost only covers deposits
you still need to implement API according to standard for anchors https://github.com/stellar/stellar-protocol/blob/...
You're confusing the different layers here.
Path finding is implemented, and has been, since day one. It is only used for (path) payments, however.
When you make a buy/sell order, it is applied to a specific order book, between two assets.
Path payments are done one layer up, bridging order books to find a path from asset A to asset B by chaining together ...
Based on the orderbooks for different asset pairs you could use some graph algorithm like Dijkstra for the best path.
Pathfinding is implemented in Horizon. You can find the code on github: https://github.com/stellar/go/tree/master/services/horizon/internal/simplepath