The DAO wants a way to award things to avatar holders, such as a "mentor" badge etc. Similarly, mentors would like to award their trainees custom badges that don't necessarily involve the DAO's decision or approval. A mentor, for example, may award a certain "challenge" badge for something they use during training.

Previous attempts like have been made, for example this one involving adding a mapping to the avatar NFTs, on which the DAO could flick some properties on in an avatar:
#14

The problem with this is that when an avatar is transferred, all its properties are transferred with it. We wouldn't want the mentor badge to persist when a mentor sells the avatar NFT. And we wouldn't want the mentor to loose that badge either.

Alternatively, the badges could be assigned to addresses, and the ideal contract for this kind of record keeping could be ERC1155 NFTs.

The DAO could issue these in future stages to avatar holders, as could mentors, etc.

Subtasks

• Confirm decision
• Audit https://ogg.scopelift.co/
• Create new multisig with same addresses as L1 - Done 0x8cbecc838DEA01d3dd6828615a38fc4486D9F326
• Validate multisig instance bytecode - Matches
• Test L2 multisig - Sent it 0.03 ETH and back
• Send existing funds to L2
  • Agree on method - will send 12k sUSD to one of the signer addresses, swap it to USDC or DAI, bridge it to L2, then send it to the multisig on L2
  • Send all sUSD to an EOA - sending to 0x45a10F35BeFa4aB841c77860204b133118B7CcAE
  • Swap all sUSD to DAI
  • Bridge all DAI to L2
  • Send DAI to multisig
• Verify multisig on Etherscan

Resources

https://jaypegsautomart.com/
Contract: https://etherscan.io/address/0xf210d5d9dcf958803c286a6f8e278e4ac78e136e#code

Notes

Since it's expensive (and complicated) to randomly assign each tokenId to an assetId, and its not really transparent to just get a single random number like ethereans, they generate a few random numbers for the whole set.

Each tokenId belongs to one of 20 "lots". Each lot has its own random number. If the number has not yet been generated, or is not yet available, tokens have a place holder URI.

It should recognize the sale states and display different React components to dispatch a transaction that execute the associated Ethernauts contract function.

When we design bot.js to publish assets to IPFS, we will be in control of some mechanism that picks an assetId to associate it with a minted tokenId. We can be as honest as we want in this process, but the community has no way of knowing that we are actually being honest. We could know this rig this algorithm to be predictible by us, and thus be able to mint super rare NFTs from anon addresses we create. If the community cannot see a guarantee to mitigate this, the NFTs will be less valuable.

Other projects seem to be using oracles like Chainlink's VRF to generate a single random number that offsets the association:

    function tokenURI(uint256 tokenId) public view override returns (string memory) {
        uint _tokenId = randomisedOffset(tokenId,rand);
        return string(abi.encodePacked(baseURI(), _tokenId.toString()));
    }

Atm, Chainlink VRF is not supported in Optimism. They say it will be supported at some point. If we don't want to wait for them, we could deploy a contract on mainnet that relays a message with the random number to L2.

It might be slightly harder for us if we want to implement a dynamic randomness algorithm depending on ETH paid.

We'd like to have a generic and flexible mechanism by which the DAO can identify or mark certain NFTs as having a particular role, i.e. "mentor".

These should clear out when transfer.

Done, code shared here https://github.com/ajsantander/vrf

So far, main Ethernauts.sol is being developed completely disregarding event emission. It'd be good to review existing functions and see which should emit an event.

Keep in mind that events are already being emitted from the ERC721 contract that is inherited from.

See ipfs/npm-kubo#13

I was able to install native go-ipfs and start a daemon locally https://docs.ipfs.io/install/command-line/#official-distributions

https://www.paradigm.xyz/2021/10/a-guide-to-designing-effective-nft-launches/

We'd like to be able to give people the ability to make donations while minting an NFT. This will increase the rarity with which an assetId is associated with a tokenId.

This is rather controversial, but it would allow buyers to signal their support for the DAO. The DAO could use these donations to create a mentors pool, that only NFT holders marked with the mentor flag can claim on.

We want to give community members a chance to get an NFT, without having to wake up at 4 am, and even consider giving them a discount (i.e. they shouldn't have to worry about affording it).

Ethereans solved this pretty nicely, by doing a pre-sale, where only community members can purchase tokens for 2-3 days, and only after that the public sale starts.

The mechanism by which community members can vary. One possibility is to mint poaps in xdai, and use that to produce a list of addresses. The owner can then sign messages and hand them over to poap holders, which they can use to access the early sale with a discount.

We will be generating the metadata.
See format in opensea or rarity.tools

https://docs.opensea.io/docs/metadata-standards

Tasks

• Sale state enum
• Ability to set state by owner
• Early mint function
• Modifiers to protect mint functions
• General tests
• Mint tests
• Early mints with fixed price + tests