I am working on a new NFT collection on ETH with Solidity, and plan to release it on opensea as well.
We want to pause secondary sales while the minting step is active. But can't find any information on how to do that. Nothing in the OpenSea docs.
Maybe I just need to add conditions in smart contract methods but also can find info on exactly which one.
Related
I am trying to display a users transaction history in binance, including fund deposits and withdrawals as well as buying and selling of different crypto's. Does anyone know which binance API endpoints I would use to do this? It seems quite complicated in comparison to other trading platforms.
Thanks
This is the link to the docs: https://binance-docs.github.io/apidocs/spot/en/#withdraw-history-supporting-network-user_data
I can see the Wallet endpoints "Withdraw" and "Deposit", but this won't cover crypto trading will it?, The account trade list call would be ideal, but it requires a symbol input which I'm not sure how I would obtain dynamically.
I would also like this endpoint to provide me with the data so I can get the avg buy price for a crypto
Currently this is not supported. See: https://dev.binance.vision/t/fetch-all-account-orders/279/3
This is the route you're looking for to get the user trade history. The big downside is that you have to specify the exchange symbol, you cannot get the history of the account with just one request:
https://binance-docs.github.io/apidocs/spot/en/#account-trade-list-user_data
Get your account information first. You can then extract non-zero balances from here to get symbols for transactions. You can then loop through each currency pair and get its transaction history. This seems to be the most optimistic way we can get right now
You can also try to use caching. For example, you can remember balance for a particular coin, and if it has not changed by the next launch, then it is likely (but not 100%) that no transactions were made with it
You can also connect to WebSocket, but this is still a terrible crutch and requires a DOS attack to get the necessary data
Please note that here the balances for Savings wallet have LD prefix added to their ticker. For example, BTC in the Savings wallet is labeled as LDBTC
I am trying to get all the transactions by an address, because I want to get a specific transaction by the method (that occurs at a date time when a contract is created) and the an address. I know there is an API, but I can't find it.
For example, on this address https://bscscan.com/address/0xbe807dddb074639cd9fa61b47676c064fc50d62c I can see the methods of that address so I could go to the specific contract, but I can't get it by an API. Is it possible?
Would it be better to use a scraping?
You need use this free version - good way
https://bscscan.com/apis , then you can iterate every transaction.
Or do loop on all blocks and iterate every block - bad way.
TL;DR: If you use BAPI_GOODSMVT_CREATE to create multiple co-dependent movements and one of them is a transfer posting, then you need to use a wrapper - per SAP note 369518. If there's no transfer posting somewhere, a COMMIT is enough
Has anyone looked into the specifics of Note 369518?
It describes a requirement to start a new roll area before calling BAPI_GOODSMVT_CREATE for a goods receipt that depends on a previous goods movement (posted also by the BAPI within the same LUW).
What is unclear to me: Does it apply to goods receipts in general? Or somehow only to goods receipts that involve an "implicit" (sic) GI for stock in transfer?
I am looking for a technical walkthrough of the section "Reason and Prerequisites".
I need to decide if for a sequence of movements 262,102,101,261 on the same batch, the BAPI should be called in a new roll area each time. For this, the user will need to be asked to close a window if they have the maximum internal sessions already open. (Edit: The part in italics may not apply as I believe that DESTINATION 'NONE' will start a new user session)
Best I can tell, the answer hinges on the note's "machine translation" into English: Google offers the alternative phrasing "only with a real outgoing goods, inventory is read from the database", which clears it up a bit:
The BAPI looks into the buffer always, regardless of which movement type it is tasked to create. The issue is that a transfer posting (A08 in MIGO) does not update the buffer. While a "real outgoing" goods issue (A07 in MIGO) does, allowing the subsequent goods receipt to correctly detect the stock.
So only if a prerequisite movement is a transfer posting, is it necessary to start the dependent call in a new roll area.
I am trying to wrap my head around how Chainlink VRF integrates into Solidity contracts, such as in this randomly generated NFT tutorial: https://blog.chain.link/random-numbers-nft-erc721/
My question is around the actual funding of the oracle. In the Chainlink VRF documents, this warning is displayed: "Requesting randomness will fail unless your deployed contract has enough LINK to pay for it. Learn how to Acquire testnet LINK and Fund your contract." An example is given of how to fund the VRF contract with metamask and Remix.
However, I'm not really sure how this would work on a large scale. If you have an NFT "factory" that becomes very popular with potentially many requests per day/hour/minute, are you just expected to front run the funding of this VRF contract to avoid the aforementioned warning (seems like the costs would be non-trivial / hard to predict)?
Alternatively, if you wanted your NFT consumer to fund it, would you have to build in some logic that converts Ether to Link and then sends it to the oracle contract? (or make them go buy Link token?)
I could be looking at this the wrong way, but the scalability just doesn't seem well described in the documentation and only looked at from a testing / test network standpoint. Thank you.
You can:
Move the costs directly to the caller
Require LINK payment, or some other form of payment that will cover the costs of oracle request
Request the oracle data in a smaller frequency (if your use case allows it)
Are you receiving some price info from an oracle? Is it sufficient to update the price info once a day instead of once an hour?
Change your contract logic to not require (that much) oracle data
Does your factory really need off-chain random number generation? Wouldn't be sufficient to generate "random" number from the blockhash, difficulty, etc.?
My suggestion is, maybe a little awkward, but for the sake of decentralization, could work.
You charge your Contract1 with a sufficient link to get started
Charge every minter the equivalent link transaction cost in eth (+ the % that covers the costs of the trade to link and transfer between contracts)
As they mint, it is incorporated into the price and the eth is sent to Contract2.
In Contract2 simply exists a public callable function to initiate a swap for the link via routerV2 or a similar contract.
By placing a call to this function and contract, you can then just let any minter activate the swap contract function
The eth in Contract2 will be sent back to Contract1 as a link.
You could have a counter go and then call Contract2 every time the link fund is low and refill it automatically.
If you build it into the mint, then the inter will cover the fees.
I am just curious to know why Bitcoin developers choose a complicated approach like UTXO, rather than using the transaction models used by Ethereum Blockchain.
Basically, Bitcoin nodes maintain a set of all active UTXOs which have not been spent yet and any transaction that comes in is validated using this set. The nodes also update the UTXO set after every transaction.
This model is very analogous to how you'd implement a "wallet" which held currency notes and coins albeit with perfect traceability of each note in your wallet as to where you received it from! It is not complicated once you understand this basic analogy.
Consider the case where you have only a 20$ bill in your wallet. Let's say you buy a product worth 6$ with this 20$ bill. In this case, you will get BACK 14 $ in "change" and these notes are akin to the "unspent transaction outputs". These notes (UTXOs) can then be spent in any later transaction.
The advantage that UTXOs have is that each UTXO can be traced back right upto the point where the actual bitcoin was created (miner reward for example) and even upto the genesis block potentially.
This is akin to your being able to trace back the 20$ bill from where/whom you received it, and in succession being able to trace back how that person received this 20$ bill and so on and so forth until you traced it back to the Federal Reserve Bank mint where it was printed!
You can imagine how this would dramatically increase the security and trust in the system because you could validate each and every facet of a transaction.
However, this model was considered as not efficient enough for the Ethereum protocol which also has smart contract transactions which might execute frequently. Due to this, Ethereum went for a "Account state" based model which makes it far more efficient to calculate balances before and after transactions.
Here are some helpful links that might answer your question:
Considered as skewed towards a pro-ethereum viewpoint - https://ethereum.stackexchange.com/questions/326/what-are-the-pros-and-cons-of-ethereum-balances-vs-utxos
Also a Medium article which goes into more detailed comparison on the UTXO and Ethereum Account State model https://medium.com/#sunflora98/utxo-vs-account-balance-model-5e6470f4e0cf