I am creating an exchange similar to pancakeswap with limited features like exchange and liquidity only.
I am using the Pancake router contract code https://testnet.bscscan.com/address/0xd99d1c33f9fc3444f8101754abc46c52416550d1.
We are giving the price at the time of creating pair for our token with BNB by adding liquidity by calling addLiquidityETH function in router contract. Its working and creating pair. Then the value is fixed for that pair.
Having some doubts.
What is that value?
If the price of the BNB Increases in market. How can we fetch the current market price and update in our own DEX?
Is this contract will do this or we have to call any other API providing API....
I gonethrough the https://uniswap.org/docs/v2. But I didnt find the solution for above queries
Then the value is fixed for that pair
You cannot fix value at open markets.
What is that value?
You can find out about price formation in Uniswap v2 and other bonding curve exchange here. Essentially, value is set by buyers and sellers, depending on how much they buy or sell.
If the price of the BNB Increases in market. How can we fetch the current market price and update in our own DEX?
You cannot, because the value is set by buyers and sellers. You need become buyer and seller and spend money to set the price, effectively market make your token pair.
Is this contract will do this or we have to call any other API providing API
Does not make to discuss this, as your earlier assumptions are incorrect.
Related
I would like to know the amount of locked liquidity for each pair.
I used subgraph in Uniswap and got it by sorting totalValueLockedUSD in descending order.
However, Subgraph did not have the other DEX information I wanted to know.
（I used the following in Uniswap）
https://thegraph.com/hosted-service/subgraph/uniswap/uniswap-v3
How can I get one?
（it would be helpful to have an example of how to get information in specific uniswap folk DEX.）
Thanks.
Trying to understand how opensea "Make the bid" work. Whenever any interested buyer wants to buy an NFT, they have to create an offer,in which they basically sign a message(commitment)(which is not costing gas fees). I didn't understand how this thing works behind the scene. If, let say, i made an offer for 3 days and i won the bid or seller accepted the bid, and i don't have required ether(the bid amount) at that moment, then what will happen?
Auction smart contract basically take bidder amount as stake, and when auction end, if user doen't won the auction, transfer staked ether back, but in both the above process staking ether+paying transaction fees, these extra overhead is there.
Opensea doesn't follow staking of bidding amount and hence save user from paying transaction fees + staking ether. But they ask user to sign for confirmation of bid.
Can anyone explain whats technically happening?
I have gone through below links also but this doesn't answer how opensea is working.
Link 1 : https://ethereum.stackexchange.com/questions/102660/creating-an-auction-smart-contract-without-storing-the-ether
Link 2: https://ethereum.stackexchange.com/questions/110749/auction-data-on-chain-or-off-chain
In link 2, they mention "Commitments are created by signing "messages". These are off-chain transactions. However, cancelling transactions requires posting on-chain." But how is it actually working?
I'll explain how the newest version of Opensea works, called Seaport (docs).
If, let say, i made an offer for 3 days and i won the bid or seller accepted the bid, and i don't have required ether(the bid amount) at that moment, then what will happen?
Simply your offer won't be fulfillable. Opensea's UI should filter unfulfillable offers so they don't get accepted. If an offer is accepted by mistake, nothing bad happens, the transaction simply fails and no token is transferred.
The job of the smart contract is not to store offers, but to verify that an offer is valid and to transfer the tokens accordingly.
It may be a surprise, but the only data stored on the contract are the following mappings
// Track status of each order (validated, cancelled, and fraction filled).
mapping(bytes32 => OrderStatus) private _orderStatus;
// Only orders signed using an offerer's current counter are fulfillable.
mapping(address => uint256) private _counters;
The first mapping ensures that an order can't be fulfilled multiple times or if it was cancelled. (The order is recognized by its bytes32 hash).
The second mapping saves a counter for every offerer. Every offer has a counter parameter that should match _counters[offerer], otherwise it's invalid. This is a smart way to cancel all your existing offers, because you have a "cancel all" function simply increment your _counters.
This should have answered why to cancel orders you need to have a on-chain transaction. Because nothing guarantees that an offer is forgotten by everyone off-chain.
Opensea doesn't follow staking of bidding amount and hence save user from paying transaction fees + staking ether. But they ask user to sign for confirmation of bid. Can anyone explain whats technically happening?
The "confirmation of bid" is a wallet signature (EIP-712) necessary to make the process trustless. No one will be able to steal tokens by forging offers. The only trusting assumption is that Opensea won't hide an offer from a buyer/seller.
I have a database table at the backend, that provides various items for sale and their prices as well. For the sake of simplicity, let us assume that the schema for the same is like so:-
class Product(models.Model):
item_id = models.Integer()
item_name = models.CharField(max_length=30)
item_price = models.CharField(max_length=30)
item_count = models.Integer()
There is an API getProducts(), that is used to show to the enduser all the products available, including their price.
There is another API buyProduct(product_id), exposed to the enduser, using which he may purchase the item after seeing its price. There is a third API, updatePrice(product_id, new_price) available to the administration backend using which the price may be modified.
Now w/o having a database transaction that spans across >1 HTTP requests, how can I ensure that the API buyProduct() succeeds only if the price is the same as what the enduser saw (basically whatever getProducts() had returned last to the browser). It is possible that a customer sees the price of a product as 1$, and clicks BUY, but simultaneously the price at the backend was changed to 2$.
I have two solutions:-
Fix the buyProduct() API to include a price, which indicates
whichever price that was shown to the enduser. If the product price
has changed, throw an error.
Include a GUID against the products which represents the version of
the product row. This is then carried all the way to the enduser's
browser(but not shown to the user), and quoted in the buyProduct()
also. Anytime there is a modification to any row in the Products
table, the GUID will get updated. buyProduct() will ensure that at
the time the API is executed, the product's GUID should be what the
API carried.
I believe <2> is the way to go, since even the item_count is prone to change. But is this how everyone does things? Is there a django pattern to solve this?
Just realised that the E-Tag header and the Cache-Control headers in HTTP seem to be a recommended way to avoid data corruption. But do folks really follow this way? I found a link about this here
When working with bill items through the REST API, there is a field called tax_type on the response body that seems to (at least to me) always return with tax as its value.
I thought that a tax could be classified as inclusive or exclusive (as in the tax is included on the item's price or is to be charged separately).
Any ideas on what this field means?
A JSON sample can be seen at https://www.zoho.com/books/api/v3/#Bills_Get_a_bill
In Zoho Books, taxes can be either simple tax (tax) or compound tax (compound_tax) or tax groups (tax_groups). In Settings -> Taxes, You can create these type of taxes.
If you associate compound tax to the bill, you will get the tax_type as compound_tax.
PS: is_inclusive_tax node is used to find the bill is either inclusive or exclusive.
I'm modeling a stadium tickets database. I have a TICKET,FAN, CARD, EVENT, SEAT and SECTOR entities (and others). There are areound 40k seats, and 45 sectors. The price is calculated like this more or less:
The EVENT has a base price
The price changes depending on the SECTOR
Depending on the FAN age he could have an ulterior discount
The FAN has a CARD and depending on which type of card he could have a discount
TICKET is linked with a 1:1 to everything except CARD and SECTOR (but SEAT is weak towards SECTOR so he can see its key)
Should I calculate the price in my database? Only if I need to store it? If yes how should I do it, leave it as a calculated field in TICKET?
I hope I've been clear enough, thank for every answer
EDIT: I don't want the sql code to calculate it
I consider it a good idea to have that algorithm implemented in the database, such as to use the same algorithm and code from every app or webservice or whatever you intend to build some day.
I would create a stored procedure to calculate the price. You would call this procedure whenever you want a price calculated.
Once a ticket is issued, its price is fixed however, so you would usually store the price with the ticket. Later you may change discounts, so the same kind of ticket gets cheaper, but the one already sold doesn't of course. That said, use the stored procedure to calculate the ticket price initially. When issuing the ticket, store that current price with it.