Allow me to provide you a quick background: I programmed back at collage [1990-1992], thus I got some logic and programming foundation. Today I am embracing a new challenge Project Highlights: to create a sound and secured ERC20 token with an associated Smart Contract in which Token holders [via API] will be able to: a) Access Documents (DocumentName, AccessKey), b) Exercise [5] Voting Rights (FinancingGateName, Vote[yes/no]) and c) View Net Profits [given by Contract Owner] (ProfitSource, Value [ETH], IssuedTimeStamp, Hash).
The Five Voting Rights will trigger the following actions:
Approve the issuance [mint] of additional Tokens [stage 2] and make them available in an exchange.
Approve the release [from escrow] of 100% of the funds received (ETH) from the Tokens [stage 2] to the Contract Owner.
Approve the issuance [mint] of additional Tokens [stage 3] and make them available in an exchange.
Approve the release [from escrow] of 30% of the funds received (ETH) from the Tokens [stage 3] to the Contract Owner.
Approve the release [from escrow] of 70% of the funds received (ETH) from the Tokens [stage 3] to the Contract Owner.
Prior to developing the above described Smart Contract, I will issue an ICO [stage 1] with a conditional success threshold of 70% of tokens sold, equivalent to x number of ETH; if not met, the received funds [ETH] will be returned to the originators.
With this scenario, I believe I can leverage many of the OpenZeppelin contracts that engage with ERC20.sol, Crowdsale.Sol, Escrow.Sol, etc. I still need to do further research on Voting/Ballot Contract Samples to obtain and leverage best practices, given that I did not see any related contracts in OpenZepelin GitHub.
By reviewing openzeppelin.org and zeppelinos.org I figure that I would be able to take sound steps by leveraging a modular approach with OpenZeppelin Contracts and by deploying them via ZeppelinOS.
Therefore, here are my first set of questions:
Could you guide me on how to best take advantage of a modular approach? That is, how to best interact with the existing or modified versions of OpenZeppelin contracts?
Could you guide me on how to best take advantage of the Roles.sol?
When deploying a contract that calls [import] other contracts, which call [import] other contracts, via ZeppelinOS, are all those called contracts bundled up and sent to the Main or Test Networks as ONE Contract?
Are there any other OpenZeppelin Contracts.sol, not mentioned in this message that I should review/consider to leverage into my project?
Hello @jaureguino, this seems rather complex!
I know I’m not frangio but I’ll answer what I can haha
Not entirely sure what is being asked here, how do the voting rights affect the users?
Roles allows you to mark people who should have exclusivity for certain functionalities, like restricted access to certain functions. If you need a role set up I’d recommend using one the existing roles contracts and renaming it for each of your roles for what they need to be.
If it just calls other contract, as in importing their interfaces, then it won’t be bundled. You can also link it as a library. However if the contract is not already previously deployed I’m positive the contract it will all be in the same contract.
None that I’m aware of.
Let @frangio respond before going through with it all. He’ll have a better idea than I do.
Greetings again @IvanTheGreatDev, and thanks for taking a shot at these questions. Allow me to respond/elaborate further in order to provide you and @frangio with more clarity/context:
No, the question is related to how can I best interact/use/modify existing OpenZeppelin contracts as I develop my ERC20 Token and Smart Contract. i.e.: a) by calling them [import] (OpenZeppelin repository) from my contract, b) by copying them (OpenZeppelin repository) into my own repository and calling them from my contract, c) by literally integrating (copying) the libraries and interfaces into one contract (script), d) So on and so forth, I just need some best practices or recommendations…
Got it. So, since I am the only one Developer/Contract Owner/Minter, then I should not have to worry/use this? Or are there any other security benefits that I should be aware of?
So, lets say that I copy the OpenZeppelin contracts into my own repository, and call them [import] from my contract, linking them as libraries/interfaces. Then I deploy my “master” contract for the very first time, and this “master” contract calls [import] various libraries, contracts, interfaces available in my repository, then should I presume that all the calls/links that my “master” contract makes would be bundled up and deployed as ONE contract? I am fairly new on this, so I am just trying to make sense out of all this in order to make right decisions early on.
You should install the package through npm and, using a framework like Truffle, import the contracts with Solidity import statements. Please take a look at the “Install” and “Usage” sections in the README. Copying or integrating the source code is strongly discouraged, because you lose the security guarantees we try to build into the contracts.
If you’ll be developing an ERC20 token I would recommend using our ERC20Mintable extension, which uses the MinterRole. This won’t provide security benefits but more flexibility in the future. Other than the built in roles in OpenZeppelin I would suggest to stick to Ownable for anything custom you build, because roles are a complex interface that needs to be tested correctly, and we’re still building some tools for users to create roles themselves.
Every contract you define will result in a separate contract being deployed. If you define contract A is X, Y, the source code for contract A will in a sense “bundle” the source code for A, X and Y together into one contract. If you have multiple contracts in your project, each will be its own “bundle”, which would be deployed separately if you need an instance of it. But some contracts are only there to aid modularization through inheritance, and might not be deployed by themselves, such as maybe X or Y above.
pragma solidity ^0.4.24;
import "zos-lib/contracts/Initializable.sol";
contract MyContract is Initializable {
uint256 public x;
string public s;
function initialize(uint256 _x, string _s) initializer public {
x = _x;
s = _s;
}
}
However, I noticed that the ERC20Mintable extension found in [openzeppelin-eth/contracts/token/ERC20/] also calls/imports [zos-lib/contracts/Initializable.sol]. So, I presume that the Initializable.sol contract will always be there…
Q. Which library should I use to develop secured and upgradeable contracts?
If you’re developing upgradeable contracts you should be using openzeppelin-eth. Prioritize the guides in docs.zeppelinos.org, they are made specifically for your use case.
Greetings @frangio & @elopio, I hope you all are back safe from EthDenver,
As described at the beginning of this topic, this project´s scope includes both the creation of a token and a smart contact that would allow token holders to vote on five (5) different ballot events at different future periods.
Having to disable Token trading during voting periods.
Before I re-write the token creation contact I was working on (based on ERC20 logic), I have the following questions:
Could I use the ERC721 logic and still treat each Token as having equal weight/value as if it was fungible?
Do I have to create a logic that generates a unique tokenId each time I call the mintWithTokenURI function? or Did I miss something and such unique tokenId is already provided somewhere in the ERC721Metadata.sol logic?
Can I assign a single and universal “image” to each ABC_Token such as tokenURI = http://[abc].com/images/ABC_Token_Image.png ?
I’m not sure going with ERC721 is necessarily the best way to go: the questions you arise regarding URIs reflect this in a way.
What you could do is, instead of pausing token transfers during the voting period, use something like our ERC20Snapshot, which will let you store the balances of all accounts at any given point in time, and then use those to calculate voting power.
Keep in mind though ERC0Snapshot is under development at the moment and is not yet part of a release, though it will be included in version 2.2 of OpenZeppelin, in about two weeks.
Do you have an additional technical reason why you would advise against taking the ERC721 approach?
I would not mind assigning the same universal “image” value into tokenURI to all tokens, which in fact reinforces that each token has the same design/value/weight; and if we add that each tokenId is unique and distinguishable (sort of a certificate number) and that they are also whole, in other words, there are no decimals, it would “look and work” exactly as intended a “voting-right” bearer share.
Considering that a snapshot of the balances can be taken via ERC20Snapshot, then only the token holders at that snapshot moment [second] would be able to exercise their vote, and the general intention is that the token holder could still trade their token and/or exercise their vote during the voting period [one week]. The possibility to record the tokenId used during the ballot, would allow me to code the means to prevent its current or future holder (whomever) exercise that right again with the same tokenId. It is expected that a buyer of a token during the voting period may or may not be able to exercise their vote, based on the right exercised or not by the previous owner.
Since the ERC20Snapshot is still under development and I must go live with this token by March 1st, would you have any other technical or logical rationale for me to consider ERC721 a terrible choice?
I look forward to reading your response and thanks again for your contribution,
Dear @frangio or @elopio, do you guys have any other thoughts on this subject?
If what you are modelling is closer to paper ballots, then yes, ERC721 may be the way to go. Keep in mind though that, like real life paper ballots, handling multiple of these may be difficult and annoying (e.g. a user votes using their 50 ballots).
Regarding the code itself, you could simply use ERC721, leaving out the ERC721Metadata (optional) extension, and remove the need to deal with tokenURIs that way.
After finishing the reading I realized that I may not want to do the Token upgradeable. But will do so with the associated Smart Contract that will handle the three modules mentioned at the beginning of this topic. Therefore I am committed to use Zepkit (which I already installed) to test and deploy the whole Web3 Dapp with its Token and associated Smart Contract.
For the reasons explained during my last two posts, I have leveraged the ERC721MetadataMintable.sol and followed your previous advice and put together the following TFF_Token.sol contract:
pragma solidity ^0.5.0;
import "openzeppelin-eth/contracts/token/ERC721/ERC721Metadata.sol";
import "openzeppelin-eth/contracts/access/roles/MinterRole.sol";
import "openzeppelin-eth/contracts/ownership/Ownable.sol";
import "zos-lib/contracts/Initializable.sol";
/**
* @title TFF_Token http://estudios-amazonia.com/TheFaustFlick_WP.pdf
* @dev ERC721 minting logic with metadata, leveraging ZeppelinOS EVM
* @dev ERC721 facilitates preventing: a) double-voting per token and
* b) disabling trading during voting periods.
*/
contract TFF_Token is Initializable, ERC721, ERC721Metadata, MinterRole, Ownable {
address private Owner;
string private Name;
string private Symbol;
string private TokenURI;
uint256 private TokenId;
uint8[4] private MintStage;
uint256[4] private TokensToMint;
function initialize(address sender) public initializer {
require(ERC721._hasBeenInitialized());
require(ERC721Metadata._hasBeenInitialized());
Name = "TFF_Token";
Symbol = "TFF";
ERC721.initialize();
ERC721Metadata.initialize(Name, Symbol);
MinterRole.initialize(sender);
Ownable.initialize(sender);
Owner = sender;
TokenURI = "http://thefaustflick.com/images/TFF_Token.png";
TokenId = 1;
for (uint8 counter = 0; counter <= 3; counter++) { MintStage[counter] = 0; }
TokensToMint[0] = 500000;
TokensToMint[1] = 3000000;
TokensToMint[2] = 3000000;
TokensToMint[3] = 3500000;
Mint_TFF(0);
}
/**
* @dev TFF Minter function * Warning * Review White Paper and get last
* TokenId to figure out next logically correct Mint_TFF(_Stage) value
*/
function Mint_TFF(uint8 _Stage) public onlyMinter returns (bool) {
require(MintStage[_Stage] == 0);
uint256 tokensToMint = TokensToMint[_Stage];
for (uint256 counter = 1; counter <= tokensToMint; counter++) {
_mint(Owner, TokenId);
_setTokenURI(TokenId, TokenURI);
TokenId = TokenId.add(1);
}
MintStage[_Stage] = 1;
return true;
}
/**
* @dev Gets Last TokenId function * Useful to determine how many TFF Tokens
* have been minted. Helps figure the next logically correct Mint_TFF() Value
*/
function GetLastTokenId() public view returns (uint256) {
return TokenId;
}
function GetTokenURI() public view returns (string memory) {
return TokenURI;
}
uint256[50] private ______gap;
}
Could you or anyone from the Zeppelin Team be able to review/confirm/validate/correct some of assumptions I made in the following sections:
import [Do I call all the appropriate imports?]
function initialize [Are the require , the [ X ].initialize and the rest of the logic correct]
function Mint_TFF [Is the logic correct? Did I miss something?]
When deploying via ZeppelinOS, I would have to use the following command line: $ zos create ./contracts/TFF_Token --init initialize --args <address> ?
Also, when trying to deploy with $ npx zos add ./contracts/TFF_token it is calling an older version of the TFF_Token.sol file that had an array definition error, but has been fixed since.
It seems as when trying to deploy the bugged version it stored the TFF_Token.sol in some sort of cache memory, see image . I even exited the command prompt and entered back again and gave me the same error.
Hello Jaureguino! So after looking for a bit I saw that the error is actually in a different file called ABC_Token.sol. zos add actually runs truffle compile in the package so make sure there's no other errors! Or if you don't need that file then you can get rid of it as well
Try that please and let me know
For 4 it should be zos create ./contracts/TFF_Token --init initialize --args "addresshere" if I remember correctly.
What I understood from the reading, and please do correct me if I am mistaking, is that as it relates to a Token contract, what would be upgradable/modifiable, in my specific case are the metadata variables Name, Symbol, TokenURI and TokenID, and the “minting tools” MintStage[0] and TokensToMint[0], none of which I would want to change in the future since, based on our business logic (see our whitepaper http://estudios-amazonia.com/TheFaustFlick_WP.pdf), I consider them to be quite sound.
Since the foundation of the TFF_Token.sol relies on /openzeppelin-eth/contracts/ and /zos-lib/, I take for granted that I am well covered by you guys for the rest.
I could make the token contract upgradeable if I wanted to get fancy, but it would only be for the hype of it, and tedious for me to parse all those variables via command line. I am not a professional developer, nor I intend to be; I am a pragmatic businessman, so I am very conscientious on where I invest my time.
I need to get this token and the associated Smart Contract done the fastest, the easiest and safest way and then focus all my attention on what matters the most to me: sell & deliver #TheFaustFlick project.
pragma solidity ^0.5.0;
import 'openzeppelin-solidity/contracts/token/ERC721/ERC721Full.sol';
import 'openzeppelin-solidity/contracts/token/ERC721/ERC721MetadataMintable.sol';
import 'openzeppelin-solidity/contracts/ownership/Ownable.sol';
/**
* @title TFF_Token http://estudios-amazonia.com/TheFaustFlick_WP.pdf
* @dev ERC721 metadata minting logic leveraging openzeppelin-solidity v2.1.2
* @dev ERC721 facilitates preventing: a) double-voting per token and
* b) disabling trading during voting periods.
*/
contract TFF_Token is ERC721Full, ERC721MetadataMintable, Ownable {
address private Owner = 0x8045B92162Bb607454f8CF4CC44CBD9dff518495;
string private Name = "TFF_Token";
string private Symbol = "TFF";
string private TokenURI = "http://thefaustflick.com/images/TFF_Token.png";
uint256 private TokenId;
uint8[4] private MintStage;
uint256[4] private TokensToMint;
// Constructor
constructor() ERC721Full(Name, Symbol) public {
TokenId = 1;
for (uint8 counter = 0; counter <= 3; counter++) { MintStage[counter] = 0; }
TokensToMint[0] = 500000;
TokensToMint[1] = 3000000;
TokensToMint[2] = 3000000;
TokensToMint[3] = 3500000;
Mint_TFF(0);
}
/**
* @dev TFF Minter function * Warning * Review White Paper * Get last
* TokenId to figure out next logically correct Mint_TFF(_Stage) value
*/
function Mint_TFF(uint8 _Stage) public onlyOwner returns (bool) {
if (MintStage[_Stage] == 0) {
uint256 tokensToMint = TokensToMint[_Stage];
for (uint256 counter = 1; counter <= tokensToMint; counter++) {
mintWithTokenURI(Owner, TokenId, TokenURI);
TokenId = TokenId.add(1);
}
MintStage[_Stage] = 1;
return true;
}
}
/**
* @dev Gets Last TokenId function * Useful to determine how many TFF Tokens
* have been minted. Helps figure the next logically correct Mint_TFF() Value
*/
function GetLastTokenId() public view returns (uint256) {
return TokenId;
}
function GetTokenURI() public view returns (string memory) {
return TokenURI;
}
}
When the truffle-config.js file was
And I tried truffle migrate, I got
So, I changed the truffle-config.js file to
and I got
Any thoughts or recommendations on gas and gasPrice settings on the truffle-config.js or
should I adjust the GAS LIMIT and GAS PRICE on the ganache configuration here
Project Highlights: to create a sound and secured ERC20 token with an associated Smart Contract in which Token holders [via API] will be able to: a) Access Documents (DocumentName, AccessKey), b) Exercise [5] Voting Rights (FinancingGateName, Vote[yes/no]) and c) View Net Profits [given by Contract Owner] (ProfitSource, Value [ETH], IssuedTimeStamp, Hash).
. I even exited the command prompt and entered back again and gave me the same error.
?
