Yarn add OpenZeppelin Contracts 2.5.1

Support Contracts
1

Hi @abcoathup , I think I have a similar issue to @wat .

My project uses an interface which requires open zepplins IERC20 contracts, the catch is that it is in solidity version 0.5.

I tried installing

However I get:

error An unexpected error occurred: "https://registry.yarnpkg.com/openzeppelin%2Fcontracts: Request "https://registry.yarnpkg.com/openzeppelin%2Fcontracts\" returned a 405".

I am using yarn add, that could be the source of the issue, justt checking if you guys still support openzeppelin/contracts@2.5.1 package?

1 Like
2

Hi @Graeme_Barnes,

Welcome to the community :wave:

You can use OpenZeppelin Contracts 2.5.1

You should be able to do yarn add @openzeppelin/contracts@2.5.1

$ yarn add @openzeppelin/contracts@2.5.1
yarn add v1.22.4
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...

success Saved lockfile.
warning Your current version of Yarn is out of date. The latest version is "1.22.5", while you're on "1.22.4".
info To upgrade, run the following command:
$ sudo apt-get update && sudo apt-get install yarn
success Saved 1 new dependency.
info Direct dependencies
ā””ā”€ @openzeppelin/contracts@2.5.1
info All dependencies
ā””ā”€ @openzeppelin/contracts@2.5.1
Done in 1.37s.
3

That you very much for the quick reply. It was an error on my side, I didn't add the @ symbol in front of the package name.

Not sure if other dev's have run into this issue but my project requires open zepplin's solidity V5 and V6. Open zepplin's version write over each in the dependancy file. I expect this is normal behaviour, but its breaking my project.

Do you have any tips for having two version of open zepplin's contracts in one project?

1 Like
4

trying out Yarn's alias command.

with command: yarn add openzepplin-v5@npm:openzeppelin/contracts@2.5.1

But unfortunately compiler throws up this is:

An unexpected error occurred: "https://registry.yarnpkg.com/openzeppelin%2Fcontracts: Request returned a 405".

Guess I'm formatting the command incorrectly .

1 Like
5

Correct command was

yarn add openzepplin-v5@npm:@openzeppelin/contracts@2.5.1. Iā€™ll update on the thread if this works when working with two version of open zepplin.

1 Like
6

Whoop, looks like that did the trick :slight_smile:

1 Like
7

I was about to ask a similar question.

I currently have "@openzeppelin/contracts": "^3.3.0" in my truffle dependencies, but would also need 2.5.1 (!) because I want to add a Crowdsale ā€¦ can I use both?

@Graeme_Barnes is yarn add openzepplin-v5@npm:@openzeppelin/contracts@2.5.1 actaully doing what I want ?

@abcoathup is there more documentation and maybe even examples for Crowdsale then (more of less) just the function names ?

1 Like
8

Hey, ya this works for my project in hardhat. Basically Iā€™ve got on solidity file in solidity version 0.5 which requires the openzeppelin contracts 2.5.1.

However Iā€™ve got another solidity file in version 0.6 which requires open zepplinā€™s ownable module and a few others.

If you go ahead and run yarn add open zepplin/contracts it will over write the old contracts 2.5.1.

Giving the 2.5.1 contracts alias just means that it wont over write the zepplin/contracts. This allows me to use an import statement like:

import "openzepplin-v5/token/ERC20/ERC20.sol";

whilst in my solidty version 0.6 contracts I have:
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

and yeah it works.

1 Like
9

Hi @Graeme_Barnes & @sven.meyer,

Hardhat supports multiple Solidity versions in the same project. This isnā€™t supported in Truffle.
I havenā€™t tried running OpenZeppelin Contracts 2.x and OpenZeppelin Contracts 3.x in the same project though.

As for a Crowdsale, you could just have a separate project with your Crowdsale contract to use OpenZeppelin Contracts 2.5.1.

The Crowdsale documentation is here: https://docs.openzeppelin.com/contracts/2.x/crowdsales
There is a Simple ERC20 Crowdsale example in the forum too.

10

@abcoathup

Going to setup a separate project for the Tokensale.
The other project uses truffle , OpenZeppelin contracts v3 andsolc 0.6.12

Can I define an interface in the , derived from the Cowdsale contracts which use solc 0.5.17 , and compile that with 0.6.12

Just wanted to make sure that the have not changed anything in the call interface ā€¦

// SPDX-License-Identifier: MIT

pragma solidity 0.6.12; // ^0.5.0;

// https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/validation/IndividuallyCappedCrowdsale.sol
// https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/access/roles/CapperRole.sol

interface IndividuallyCappedCrowdsaleInterface {

	/**
	* @dev Sets a specific beneficiary's maximum contribution.
	* @param beneficiary Address to be capped
	* @param cap Wei limit for individual contribution
	*/
	function setCap(address beneficiary, uint256 cap) external; /* onlyCapper */

	/**
     * @dev Returns the cap of a specific beneficiary.
     * @param beneficiary Address whose cap is to be checked
     * @return Current cap for individual beneficiary
     */
    function getCap(address beneficiary) external view returns (uint256);

	/**
     * @dev Returns the amount contributed so far by a specific beneficiary.
     * @param beneficiary Address of contributor
     * @return Beneficiary contribution so far
     */
    function getContribution(address beneficiary) external view returns (uint256);

	/**
	 * @dev Capper is the account/role allowed to execute setCap
	 */
	function isCapper(address account)  external view returns (bool);

    function addCapper(address account) external; /* onlyCapper */

    function renounceCapper() external;

}
1 Like
11

Hi @sven.meyer,

I am not sure why you need to create a crowdsale interface. Are you planning to interact with your crowdsale from another contract?

You can just deploy your Crowdsale and interact with your token using IERC20.

12

@abcoathup Exactly. The idea is to setup a IndividuallyCappedCrowdsale and have another contract which will determine how much a certain user will be allowed to purchase.
That other contract would have to call the setCap function.

I am still thinking what the right pattern would be to connect them:

  1. Deploy the Crowdsale first and provide the crowdsale address to the constructor of the other contract

  2. Deploy both contracts ā€œas isā€ and execute a ā€œsetCrowdsaleAddressā€ thereafter (make it even "update-able by an admin , what could be regarded either as ā€œconvenientā€ or a ā€œsecurity riskā€)

  3. Have a 3rd ā€œgovernance contractā€ to hold the addresses of each contract, which can be requested by the other contract. (potentially also update-able)

I think technically it all should work, I am just wondering what would be ā€œgood practiceā€ ?

[UPDATE] ok, might work with a normal program, but if I change (set) a new address for an external contract, that does not (automatically) result in the contract updating the instance / reference to the external contract ā€¦ so option 2) might not be a good solution, unless the ā€˜setā€™ is forced to be executed only once before use.

One more question : Can I sell a token for something else than ETH, like DAI, ā€¦ ?

1 Like
13

The Crowdsale contracts in OpenZeppelin Contracts 2.x only accept Ether. You could create your own crowdsale contract (using the concepts from Crowdsales) or you could look at using a decentralized exchange to sell tokens.