guminc / contracts Goto Github PK

Scatter.art NFT contracts. See contracts-exchange repo for Marketplace contracts.

Solidity 54.79% TypeScript 42.77% JavaScript 2.44%

contracts's Introduction

Advanced Sample Hardhat Project

This project demonstrates an advanced Hardhat use case, integrating other tools commonly used alongside Hardhat in the ecosystem.

The project comes with a sample contract, a test for that contract, a sample script that deploys that contract, and an example of a task implementation, which simply lists the available accounts. It also comes with a variety of other tools, preconfigured to work with the project code.

Try running some of the following tasks:

npx hardhat accounts
npx hardhat compile
npx hardhat clean
npx hardhat test
npx hardhat node
npx hardhat help
REPORT_GAS=true npx hardhat test
npx hardhat coverage
npx hardhat run scripts/deploy.ts
TS_NODE_FILES=true npx ts-node scripts/deploy.ts
npx eslint '**/*.{js,ts}'
npx eslint '**/*.{js,ts}' --fix
npx prettier '**/*.{json,sol,md}' --check
npx prettier '**/*.{json,sol,md}' --write
npx solhint 'contracts/**/*.sol'
npx solhint 'contracts/**/*.sol' --fix

Etherscan verification

To try out Etherscan verification, you first need to deploy a contract to an Ethereum network that's supported by Etherscan, such as Ropsten.

In this project, copy the .env.example file to a file named .env, and then edit it to fill in the details. Enter your Etherscan API key, your Ropsten node URL (eg from Alchemy), and the private key of the account which will send the deployment transaction. With a valid .env file in place, first deploy your contract:

hardhat run --network ropsten scripts/sample-script.ts

Then, copy the deployment address and paste it in to replace DEPLOYED_CONTRACT_ADDRESS in this command:

npx hardhat verify --network ropsten DEPLOYED_CONTRACT_ADDRESS "Hello, Hardhat!"

Performance optimizations

For faster runs of your tests and scripts, consider skipping ts-node's type checking by setting the environment variable TS_NODE_TRANSPILE_ONLY to 1 in hardhat's environment. For more details see the documentation.

contracts's People

Contributors

Stargazers

Watchers

Forkers

jdgc dennisdv24 nareph iotaorigin lucaswongc mini-labo kneelsdev

contracts's Issues

Enable BurnToMint on ERC1155 collections

Fix price computation for lists with bulk discounts and unitSize

This transaction fails when we send a value of:

0.01: ExcessiveEthSent
0.001: InsufficientEthSent

However, sending 0.008 ETH succeeds.

Here is how we're computing value on frontend:

  const valueBN =
    invite.currencyAddress === ethers.constants.AddressZero
      ? priceBN.mul(quantityBN).mul(unitSize)
      : ethers.BigNumber.from(0);

This equals 0.01 ETH, that's why we see ExcessiveEthSent on the frontend.

However, when I use the computePrice method on the contract with these inputs I get this:

New list feature to check token holder status in contract at mint-time (rather than snapshot-time)

Sometimes we want people to buy a certain NFT and then be able to mint another NFT, maybe they get a discount for owning another NFT which can encourage its minting / buying so its floor goes up.

We want it to be dynamic for this list feature, as in the list has a set of contract addresses instead of wallet addresses.

Figmata VIP for example is dynamic not snapshot based.

Unisocks / radbro style bonding curve for list prices

Bonding curves can help with price discovery, for highly desired projects the price may keep going up, for others it may go zero

https://etherscan.deth.net/address/0xabcdb5710b88f456fed1e99025379e2969f29610

https://etherscan.io/address/0x8ebaab2d542278b81ad95793b0b0c174a64494c3 is the contract deployer for Fumo and should have ref for their style of bonding curve https://fumo.remilia.org/

Invitelists: Award token holder a dynamic number of mints based on their token count

The current invitelist system is typically based on an "egalitarian" snapshot where all holders are combined into a single list, and no distinction is made between token balances. This benefits holders of a single token, but indirectly punishes large whales/holders.

One feature worth exploring is whether it is possible to make the number of eligible mints (wallet limit) dynamic based on token balances.

Expand BurnToMint to allow burning ERC20 tokens

context

Deploy contracts to other chains

Deploy DN404 & ERC721 contracts to:

Blast
Blast testnet *
Base
Base testnet
Berachain
Berachain testnet

Need:

Contract factory
Contract implementation

*Note: DN404 factory already deployed to Blast testnet:

VITE_CONTRACT_FACTORY_DN404_BLAST_SEPOLIA=0x641d18e156F7150CcF94a8f73cfD3B544f13ab31
VITE_IMPLEMENTATION_DN404_BLAST_SEPOLIA=0x690eb624DFBd36f83a8092E3F586b733Df827baA

Expand BurnToMint to include multiple collections

context:

Make minted variable public

Would like a way to inform user whether they've exceeded their mint limit for an invite list:

So instead of limit: 1, should show limit: 0/1.

One approach to doing this on-chain is to make this variable (https://github.com/scatter-art/contracts/blob/main/contracts/Archetype.sol#L114) public:

  mapping(address => mapping(bytes32 => uint256)) private minted;

Calculate transaction value via a public method

To make it easier for third parties to interact with our contracts, we need a function that accepts mint params and outputs transaction value.

It is too complicated to require them to calculate affiliate discounts and bulk mint discounts themselves.

Should work for both ETH and ERC20 (0 value).

Should work for ERC1155 and ERC721.

Does not need to work for executeBatch bulk transactions.