Assume vesting code block in Plutus playground. Simply, if receiver wallet has some ADA, the contract works normally. But in case of an empty receiver wallet, transaction will fail because sending money from script to wallet needs an amount of fee and this fee should be paid by receiver. Any modification for such problem?
That's not a problem, that's the way smart contracts works in cardano, even that's the way everything works on blockchain. When an address sends money to another, the source address should pay for the fees. That logic applies to any blockchain (as I know).
So, in smart contracts is the same. If a wallet wants to retrieve (not receive as you said) money from a validator script, then should pay for the fees. This is because the wallet wants those funds, therefore it should submit a transaction in the blockchain, that implies to pay the fees for it.
In blockchain, every user/wallet/addres that submit a transaction to the network, should pay fees.
Related
I'm working on a project to create an NFTs marketplace.
When an NFT is listed, the owner can transfer that NFT to another wallet and the listing would still be there.
This raises a few problems:
When the NFT is returned to the original, the listing is up again and bots can snipe the NFT if the listing is below the floor price.
Buyers can still call the function but the transaction will be reverted, buyers would receive no NFT and lose the gas fee.
Apparently, Opensea is fighting this problem using front-end solution. CMIIW.
You can see more below:
https://opensea.io/blog/safety-security/important-updates-for-listing-and-delisting-your-nfts/
https://support.opensea.io/hc/en-us/articles/4415742560403-What-is-an-inactive-listing-
Are there any other ways for the smart contracts to recognize the NFT being transferred out of the wallet and make the listing invalid, only using smart contracts?
I'm new in solidity and erc20, so I read ERC20 description on the openzeppelin and find this function which isn't clear for me.
approve(spender, amount)
What's the purpose of allowing to the spender spend my token, instead of send my tokens to the spender directly?
You can change the approved amount or revoke it altogether (only the unspent amount). But you cannot take back an already sent transfer.
A common use case for the approve() function is trading on a DEX (decentralized exchange). You approve the DEX contract address to spend your USDT tokens for example. And when you want to buy an XYZ token (against USDT), the DEX simply pulls the already approved USDT from your address and sends you the XYZ tokens.
Approve is a function used to give permission the spender can be anyone an exchange or EOA to withdraw as many times from your token contract up to the _value.
You can check this reference here
As others said, Approve function can give permission to the spender to pulls the amount of token in your address. It can be used in: DEX (decentralized exchange) or in Custody services.
In custody services, after you approve the custody provider to take your token, whenever your wallet receives token, the custody provider is able to transfer your token into some internal wallets and keep them save for you. (It's just like how the traditional banks work)
My naive understanding behind how currency trading works on Exchanges like Binance and Coinbase is each users are provided with unique address and when the respective currencies trade happens on exchanges like Binance or Coinbase, both the parties accounts get's updated live on blockchain.
To elaborate more, In case of ETH/BTC trading, let's say, Mr Foo wants to trade his ETH with Mr Bar's BTC on Binance exchange. Binance will provide both of them with unique address respectively to their currency. So when the ETH/BTC trade take place, Mr Foo will receive the BTC on his newly generated unique BTC address and Mr Foo's ETH account will be deducted . On the other side, Mr Bar's BTC account will be deducted and Ether account is updated with newly received ether.
I'm really confuse regarding whether these currency trading on exchanges execute live on Blockchain? Recently during Bitcoin and Ethereum network congestion, I did BTC/ETH trading on HITBTC, the process happened instantaneously, but I've to wait for hours during withdrawal process. Also Hitbtc seems to be using same Ethereum account (0x65e2c5175e2e618f48e70343b14c31b280e42d90) to transfer fund during withdraw request for multiple users. It seems that these exchanges are using the same address for serving multiple users.
Could somebody explain how users accounts are updated during currency trading on exchanges like Coinbase and Binance? Does trading immediately happens live on blockchain? Or Exchanges only shows the users with fake trading balances until it's withdrawn? Do the Exchanges use same address to accept deposits from multiple users?
Thank you for your time.
Check out this thread for a brief explanation of Coinbase's order management.
Answer on the reddit thread, supposedly from a coinbase insider.
In addition, my comment above was just based on intuition and my general knowledge of the way brokers work.
Brokers
Brokers tend to match orders first since they are in the business of exchanging, not investing. Meaning they make their most consistent revenue from fees generated by facilitating customer orders, not by investing in the securities or assets that they help to buy/sell.
Sometimes in order to fulfill an order the broker will go long or short a particular asset class, in this case bitcoin or ethereum, etc. If this happens the broker is exposed to fluctuations in the price of that asset against the asset they are trying to grow (cash).
Now, since Coinbase is heavily involved in crypto it might be part of their strategy to hold Bitcoin or Ethereum inventory, but I would doubt it would figure much since that would undermine public trust in their institution as an impartial exchange. No one really likes to hear their broker bet against them, it tends to engender resentment.
Technicals
Coinbase is setup as a software wallet, meaning you have an account, with the private keys stored on their server. So it is possible for them to facilitate some of the trading between bitcoin accounts without ever having to match orders with an account holder outside their system.
Meaning, they can collect/match/fill the orders in batches and then submit those batches to bitcoin miners. This would allow them to quickly "fulfill" your order, and then send you verification once it has been posted to the blockchain.
Further Reading
Although it is not specifically geared towards crypto exchanges there is an excellent book on the subject of how markets actually function.
Market Microstructure in Practice
I am building and app which will offer payment in bitcoins. I know that when I send bitcoin from one address to another it can be tracked by blockain API to verify the transaction. After receiving some assets I want to send some assets back. The customer will have an input field where he will paste his deposit wallet address. I am subscribed to blockchain API to track received assets to my bitcoin address. How can I verify that the payment was made by certain customer? Checking his address doesn't seem to solve the problem because if customer uses wallets like Coinbase, Bitstamp etc. transaction is made from multiple addresses.
A few helpers here:
What you need to do is to generate a new address and give it to your customer. This way you can uniquely identify him
Wait for confirmation before making the decision. Just because you see a transaction, does not mean you have the money. You need to wait for a few blocks and several (>6) confirmations
(Not sure if this is the right place to ask. Please point out other forums if that's not the case).
I'm based in Europe, and I've set up an invoicing system for a client of ours which uses a tokenization system provided by his bank, as part of the bank's secure payment services. (In other words, this is not any of the big american services like Paypal, Braintree, Stripe...).
The problem is that, in order to input a credit card into the system, this
bank needs to charge an initial amount of 0.01 € to it... and when it does that, the credit card owner gets a text message code to approve that charge, without which the card number cannot be introduced. This is not practical for my client, for a variety of reasons. We have asked the bank, and they say that this is all dependant on the card issuing bank, and they can't do anything about it.
My question is...: what do we do to avoid this? From what I remember, other tokenization system I've used also had an initial 0.01 cent charge, and yet I never received any text messages from them (this was a few years ago, admittedly, before 2FA became widespread). How do the big payment processors (Authorize.net, Stripe, etc.) manage to store credit cards without making an initial charge and triggering two-factor authentication in the process?
Thanks.
The reason behind performing an authorisation (not a charge) is to ensure the card is valid before it is stored.
However, the $0.01 authorisation is now considered 'the old way' of doing this. Most card acquirers now allow an authorisation value of $0.00 to be used solely to check the card is valid. This shouldn't trigger any 2FA where it is supported.
Obviously though, this is payment processor dependant on whether they support this 'new' functionality. A small number are still stuck in their ways
The other alternative is just to process the full transaction value. It shouldn't be necessary to submit the card for tokenisation before using it, though admittedly this depends on your business use case.