Hot answers tagged

4

Yes, assuming that the offers are completely fulfilled (i.e. not partially fulfilled), they're removed from the account and reserve lowered.


3

The link provides purpose in a nutshell: Passive offers allow market makers to have zero spread. If you want to trade EUR for USD at 1:1 price and USD for EUR also at 1:1, you can create two passive offers so the two offers don’t immediately act on each other. As in the example above, with normal offers those two offers would cancel each other out and ...


3

I think the confusion comes from the fact that Stellar offers amount is always quoted in the amount of the selling asset. When you are selling 10000 XLM for USD the ask offers shows 10000 as expected, since you are selling XLM. When you are buying 10000 XLM for USD, it is effectively an offer to sell USD for XLM. The amount of USD is given by the XLM ...


2

It is the MANAGE_OFFER_CROSS_SELF error described in the guides and it prevents you from unintentionally fullfilling your own previous offer: The account has opposite offer of equal or lesser price active, so the account creating this offer would immediately cross itself. You should have a look at passive offers for this case.


2

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 ...


2

You have to provide buyAmount instead of amount in manageBuyOffer operations. The 400 error on the testnet may be cause by different reasons: no trustline, not enough funds, invalid signers, etc. Check the extras.result_codes field in the error object itself.


1

If each product you are selling is unique (say, art objects), all of them can be treated as non-fungible tokens. Take a look at my write-up on different Stellar-based NFT approaches here. SDF has no plans to implement NFTs on-chain in the nearest future, therefore, the best option (at least, my favorite one) is using accounts as NFTs. It requires some custom ...


1

Or just post the product as an offer, given you've created an asset for it. Whoever takes the offer takes the product. If one wants to let the buyers bid, let them submit offers and the seller will just take the highest bid. I think this is a good application of Stellar's exchange.


1

Don't know a good solution without drawbacks but here are some more ideas: Publishing the sequence number alone wouldn't be sufficient since the seller would also have to sign the transaction if they are the tx source. Now as you need a co-signing service anyways, you could create temporary source accounts for every product instead. Then co-sign any ...


1

I think the underlying problem is that the number 100/9 has infinite decimal digits and cannot be represented as string. The price you see, 11.1111111 is a truncation of 11.11111111.... = 100/9. When you enter the number 11.1111111 the SDK correctly converts it to its fractional representation 111111111/10000000. The only way to get around this is to always ...


1

According to the Stellar developers' guide, a trade is effected when a second offer matching the first is posted.


1

It's contained in the horizon response which can be decoded like this: response = builder.submit() result_bytes = base64.b64decode(response['result_xdr']) tx_result = Xdr.StellarXDRUnpacker(result_bytes).unpack_TransactionResult() offerId = tx_result.result.results[0].tr.manageOfferResult.success.offer.offer.offerID print(offerId)


1

If you manage those "in-flight" transactions on your side, it won't be a problem. Call horizon.loadAccount('GD...QZ'). Check the subentry_count field. It shows the total number of trustlines/offers/data entries for the account. Here you can calculate a minimum required balance for that account. As you mentioned, (2 + subentry_count) × base reserve. Iterate ...


1

It is not something that is currently supported. If you want to suggest adding it to the protocol you can do that by creating a Pull Request here


1

I think it is a feature with NodeJS. They don't go deep to reveal every detail down an object. Note the difference at console.log: offerResult.records VS offerResult server.offers('accounts', distributor.publicKey).call().then(function (offerResult) { console.log( offerResult.records ); }) gives > [ { _links: { self: [Object], offer_maker: [...


1

I found the answer. I was not representing the Assets that I need to sell properly. Replacing MCoin with new StellarSdk.Asset('MCoin', 'GCKRPJXPGNHBPMRCXEX4MDH532BN5RLUJJOMVACA3CB7E2LWSTKTB5U2') solved the problem. Ideally, an asset is Stellar is represented by its code and the issuer account Id. Final code becomes: server.loadAccount(distributor....


1

If you pass a string as a price in Operation.manageOffer JS SDK will use continued fraction approximation algorithm. I've just checked it and it approximates 41.5 to {n: 83, d: 2} which is fine. Not sure how you got 41.499999. Because low level code in stellar-core operates on fractions you may want ot pass a fraction directly in JS SDK. This can be done by ...


1

The prices submitted to the blockchain must be in the format specified by the Stellar docs to actually reflect your intention. As for representing it on your client (or storing it on your server), you can use whatever format you want as long as you can convert it back to Stellar's representation. It may be easier to use a format that shares the same base ...


1

Both would be fine. Caution: keep your price with at least 10 decimal places, because the system treats the bidding/asking price as fractions. Each price is stored as 2 integer variables: numerator and denominator. An offer is taken only if: (bidding price * asking price) <= 1.0000000000 . If my memory is correct, both the numerator and denominator ...


1

As far as I know, there is no other way at the moment. If you would do 1 operation with base fee per second (which is most probably huge overkill) for one day it would cost you less than 1XLM. Even at 1 ops/sec it shouldn't be serious problem to the network because it's able to run about 1000 ops/sec. Also, fees are not going to be burn, but redistributed (...


Only top voted, non community-wiki answers of a minimum length are eligible