How then does the purchase take place and how does the purchase and sale of tokens on binance affect token prices and how?
Binance holds some amount of each token traded on their site, and manages the user balances and trades in their own orderbook and databases.
Only when someone withdraws the tokens from the site, Binance performs the withdrawal from one of their addresses, which is recorded on the blockchain. Same goes the other way around for token deposits.
Note: This post is valid for the widely-used Binance (centralized) exchange. There's also Binance DEX that uses the Binance Chain (predecessor of the currently widely used Binance Smart Chain) to manage all orders and trades.
Related
Is there a way to verify that it is possible to sell a token?
There are a lot of honeypots, so you can buy a token, but then you will be not able to sell it.
I have found that there is a possibility to estimate gas for the swap transaction e.g. on the Uniswap, but in this solution, there are some conditions. The token has to be approved and you have to own some number of the token, so it could be expensive. Do you know any other method to verify that? For example, interacting with the token contract?
Example contract: https://etherscan.io/address/0x419d0d8bdd9af5e606ae2232ed285aff190e711b#readContract
There are also tokens with 100% sell fee, but it is not easy to define the contract internal fee (there is not one method to do that).
I discovered a YouTube based scam where a fake Solidity tutorial instructs users to go into Remix and deploy a scam contract. The scam contract allows any address to withdraw the funds. It has fake comments that are hilarious, but it is really scary that this scam targets potential new people in the space.
How do I find the matching contracts from the compiled bytecode? I want to see on the blockchain which contracts match this so I can find the offending address that reaches out to claim.
If there a method in geth? What about a scanner? Maybe The Graph and a subgraph?
Should I just download the chain and query? The problem for me is chain bloat and syncing Ethereum will take forever.
Is it possible in Solidity for a smart contract to be able to interact with a specific wallet in such a way that it can pull money from it, and send money to it at any time it needs to? In this particular scenario, there will be a treasury wallet, that I want the smart contract to be able to pull from and send to at any time it needs to. Is this something that's possible with a few approvals, or perhaps is there a better, more standard way to resolve the problem that I'm having?
The treasury wallet needs to do ERC-20 token approve() on the specific wallet and then it can pull money.
For further details, check out EIP-20 spec.
I wouldike to know how can I implement 4% of fees when I sell or buy from Pancakeswap ?
PancakeSwap itself implements its fee schedule. Note that tokens can trade on multiple Uniswap v2 compatible exchanges outside PancakeSwap.
To have your own market, with your own rules, you need to start your own exchange.
You can in theory try to hack special fees into your token smart contract code, but none of the past attempts have been successful and/or they all have been scams.
I'm a product manager not a Blockchain coder, looking for a 2nd opinion and some general good practice advice. I have one question in bold, the rest is background.
Background:
We have an app in development that will write user's information into a Smart Contract on the ETH blockchain.
The SC's we deploy contain information only, no Ether.
Each user has their own SC which stores only that users specific information.
Our App allows the user to edit and update this information and then upload the changes, encrypted, into their own SC.
The user's SC address is 'tied' (sorry for lack of correct terminology) to their own Ether wallet.
I see on Etherscan (Ropsten) there is a Contract Creator address which is a constant for all the SC's our App creates.
I'm assuming that the contract creator address is unique to us, it is code we've created and as such it deploys only our Smart Contracts on behalf of our Application.
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
My Concerns:
Should there be an exploitable flaw in our code then a bad actor has a list of contract addresses to attack.
The worst-case risk to us is that a bad-actor could access each users data in an unencrypted state if a flaw exists in our publicly accessible code.
The Bad-Actor then uses that flaw and the list of smart contract addresses they can get from Etherscan to download multiple users data.
My Question
Are these realistic concerns?
If so what general directions can we look at to mitigate these risks
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
The developers are outsourced 3rd parties and excellent people to work with. But Im looking for an alternate opinion than just theirs at this time as a double check.
Apologies if the information Ive provided is confusing or incomplete.
Thanks in advance for your time.
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
As you have addressed here, data regarding the blockchain (i.e. transaction hashes, contract addresses, and user addresses) is transparently available. This is by-design with Ethereum and allows for the traceability aspect of the ledger.
Furthermore, smart contract data is potentially available to any actor in the Ethereum network. However, that is based upon the following:
In order to access the smart contract data, an actor would require the contract ABI. This interface allows code to be written to interact with the smart contract methods. Now, it is helpful to understand that this ABI could hypothetically be easily reverse-generated with enough details of how your DApp interacts with the existing smart contract.
If your smart contract logic has exploitable flaws, a malicious actor on the network could take advantage of this. This is why contracts should be well-written and unit tested with near (if not) 100% code coverage. You should also identify the potential actors in each contract scenario and be sure your test cases appropriately cover these scenarios.
If so what general directions can we look at to mitigate these risks
Given the contract scenario you have described, if the only actor who should have access to these user data smart contracts is the user them self, then you simply need to apply something akin to a function modifier to your smart contract logic. In the linked example, access to the smart contract data is restricted to a single specific Ethereum user address.
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
Sure. It sounds like you're currently using a single account to deploy the smart contracts, hence the creator address is constant. (Side note: I'm not sure why you're deploying the contract on behalf of the user with this account, it sounds like the user should be deploying their own smart contract). Regardless, you could simply create a new proxy user address each time you deploy the smart contract. However, I don't see any benefit to doing so and this would just be an example of security through obscurity.