If I have a smart contract that has the addresses of some other smart contracts hardcoded inside it. E.g. maybe my contract has the addresses of some external yield farming vaults that it periodically deposits some balances to.
Now lets say that I want to update that list of addresses and remigrate it without upsetting the operation of the current contract.. what is the best way to do it ?
Ethereum bytecode is immutable, so the simple answer is: You can't update the hardcoded addresses. You'll have to create a new contract and this time save the addresses into variables that you can update later.
Related
I'm working on a new project that I'm launching soon. The dapp is almost ok, I'm writing the contracts.
But I'm not sure I understood everything, if someone can help me :(
I would like to create a token contract with a supply fix (like 1 million), then make two pre-sales (one with and without whitelist), then a contract to sell on DEX with rewards, staking system, etc.
What is the best way to do this?
Is it possible to :
create the tokens with the first contract
transfer them to the pre sale whitelist contract
make the pre-sale
transfer the remaining tokens to the pre-sale contract without withelist
make the pre-sale
transfer the remaining tokens on the last contract, which will manage all the features of my token + put on a dex
am I right in the way I do it or am I completely wrong ?
If I'm wrong, do I have to do everything in one contract, with specific functions and flags like for the beginning and the end of a pre-dirty ?
if I do everything in one, will some smart guy be able to put the contract on a DEX and add liquidity?
I looked for several ohm/nodes project contracts, I saw the pre-sale contracts but I didn't understand when they create the token because their pre-sale contracts are just sell contracts
and I didn't understand how after the pre sale the main contract takes over
i would like a final contract like that, once the sales are finish
https://snowtrace.io/address/0xf2cfc11093edb5a2dc7f49e70a3a3a9cd4f4fee4#code
if someone can help me, thanks :)
ps : last question, in the contract i dont understand what are payees, shares, addresses and balances variables
This question covers a few different things so I'm going to split my answer up.
Answers:
I looked for several ohm/nodes project contracts, I saw the pre-sale contracts but I didn't understand when they create the token because their pre-sale contracts are just sell contracts
Presale contracts by nature are selling contracts the token contract and the presale contract are generally not the same but there are a thousand ways to do that. They receive x amount of tokens and take payment in say ETH for x tokens.
if I do everything in one, will some smart guy be able to put the contract on a DEX and add liquidity?
Anybody will pretty much always be able to add liquidity for a token because that is external to the token but there are certain ways you can prevent adding liquidity until a certain condition is met say a certain timestamp you just need to detect operations that are swaps/adding liquidity and throw an error.
ps: last question, in the contract I don't understand what are payees, shares, addresses, and balances variables
I am not entirely sure what the purpose of these are for because I am not very familiar with the BRIG protocol.
and I didn't understand how after the pre-sale the main contract takes over
The main contract does not need to take over from the presale contract because the presale contract just runs until all of the tokens are sold and then it just becomes an empty husk.
Other stuff:
In the future please split up your questions across multiple StackOverflow posts.
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.
How can I make bitcoin like transaction in ethereum (web3js particular), when I need to send to multiple addresses defferent amount in one transaction to save fee?
From Péter Szilágyi's answer on Ethereum StackExchange, it seems that it is a bit indirect as compared to Bitcoin. One transaction can only have one output, but you can create a smart contract that will be able to send to multiple outputs.
I'm trying to create a contract that will dish out regular inflation to all holders of the token. Every x period, it needs to scan the addresses and calculate their inflation, minting new tokens and adding it to their total.
What is the most cost efficient way to do this? Is it cheapest to iterate over the map and update each address, or better to calculate all values in memory and replace the map? Perhaps there is a better way I'm not thinking of.
Not sure how big the map could get, but cost efficiency is key here.
Thanks!
The cheapest way to do this is to have a smart contract function that allows a wallet holder to "claim" their inflation payment. e.g. instead of iterating over every address, you let the wallet holders to do the inflation calculation just for their address.
The cost to you is 0, just have to ensure the smart contract logic is correct
If your intention is to regularly send token/eth to account addresses I urge you to read up on the withdrawal pattern. If you do not follow the withdrawal pattern, a malicious party can set up a smart contract that will get your transaction stuck during the payout.
Instead of sending funds directly you create a map about how much each address is allowed to withdraw. This is very similar to the map about which address holds how many token.
When transferring out of your contract now, only the transaction of the withdrawing party is affected.
I am writing a test application that allows people to purchase tokens.
I am adapting the example from here: https://ethereum.org/token#the-code
Here are my questions:
What is the best way to have a registry of purchases? I would assume this can be a simple web interface that queries the block chain to see who has bought what.
If this is correct, does this mean running geth on a server in order to have the latest blockchain available and then using some kind of PHP / Javascript library in order to query the blockchain every so often?
What is the best way to sell tokens? Could this be done via a web interface or would it be best to sell via the ethereum wallet? Or both?
Lets say I want to split a token into a number of parts as such:
A: A full token = 1
B: 1/10th of a full token called a 10token
C: 1/10th of a 10token called a 100token
D: 1/10th of a 100token called a 1000token
What is the best way to represent this?
For instance, if someone owns a full token they have 100% of that tokens rights. However it would be possible for many parts of a token to be owned by different people who will share rights according to their share.
Visually, it would look something like this:
How to do this is a puzzle to me.
What is the best way to have a registry of purchases? I would assume this can be a simple web interface that queries the block chain to see who has bought what.
You can do the registry in your token sale smart-contract by making event like this
event TokenPurchase(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);
In this case you will be able to watch event log later and get all the addresses you need.
Another approach is to add a simple map to your contract like this mapping (address => uint256) public deposited; and add elements to this map on purchases.
About the representation of the registry for the users you better just take a look at ICO's you like and make it in the same way.
What is the best way to sell tokens? Could this be done via a web interface or would it be best to sell via the ethereum wallet? Or both?
I would say both. But it depends on who are your tokens for. If you sell only using ethereum wallet you will loose a lot of users not familiar with blockchain.
Lets say I want to split a token into a number of parts as such
Take a look at the solutions offered by OpenZeppelin project. Just read their contracts code and I think you'll find solutions you were looking for in this post.