Loot (Spawned): Claim individual items from your bag without transferring it. Wait for your bag to replenish, then do it again

Developer Tools & Infrastructure
#1

// Overview & Links //

This contract enables removing individual items for your bag of Loot, without needing to lock or transfer your Loot token.

Its based on this idea:

E-UqcGqWYAQNnwl
E-UqcGqWYAQNnwl1204×818 103 KB

View contract on Rinkeby:

To use it you’ll need Loot on Rinkeby, which you can get from here:

Example item on OpenSea: https://testnets.opensea.io/assets/0x171737c02531ec152c8e9969357acb47155ce5c7/104866579506273748567843570589163227334742321847896356339298006527369361515687

// Implementation Notes //

The contract is currently set up to spawn new instances of all 8 of the items within a bag of Loot as ERC1155s when the claim function is called. claim is only available to active owners of Loot. Every time this is called, the bag must wait a number of blocks before it is considered “replenished” at which point it can be used again. The number of blocks increases each time the function is called.

See a breakdown of the proposed growth rate in Google Sheets: Loot (Spawned) Growth over Time - Google Sheets

These items are minted to the current owners of the original Loot bag, allowing them to add them to their collection, gift them, list them for sale on OpenSea, or use them to fund and add new members in an item-based DAO.

There are 2 public methods to make it easy to determine if a bag is replenished and may be withdrawn from: isReplenished(bagId) which returns a simple true or false, and nextReplenishBlock(bagId) which returns the block number after which the bag may be withdrawn from next.

In this version there are 2 owner-only methods which allow for updating the rate of growth. This is based on a suggestion by @metas in discord. These functions are included in the contract with the intent to transfer governance of the growth rate to the community, ideally via Loot DAO where a community-governed multi-sig is already being set up.

// Request for Feedback //

  1. Naming: When items generated by this contract appear elsewhere (ilke OpenSea), they should have a distinct name that make it clear to viewers how the item was generated. For now I’m using “Loot (Spawned)” but want to defer to the community on how we should name this contract.

What should we call the contract and the items it generates?

  1. ERC1155 vs ERC721: This contract uses ERC1155 as a way to optimize gas fees on withdrawal, and allow for aggregated item pages on marketplaces like OpenSea. There is less support for ERC1155 across the rest of the ecosystem at the moment than ERC721. If the contract needs to be ERC721-based, it will likely require modifying the claim function to only mint 1 item at a time to avoid prohibitively expensive gas fees.

Are there any reasons we should switch to ERC721, or will ERC1155 be ok?

  1. Initial Growth Rate: The contract’s formula is currently designed to create 1,000,000 individual items in a little over a year (if 100% of the bags run the claim function as often as they can). Each claim makes the time required to replenish increase, so there will possibly be many items being created in the first couple weeks before it slows down.

Is there an alternative approach to the formula that we should use instead?

  1. Governance: In case we need to change some of the variables in the growth formula in the future, the contract currently includes admin-only functions that allow modification.

Should these admin functions be kept in? If so, should Loot DAO be asked to control governance of the growth rate?

Please leave your feedback about these questions and any other suggestions in the replies. Thanks!

18 Likes
#2

I found this is actually quite neat.

1 Like
#3

Love this. Would this contract type require gas fees for each minting?

One comment: I’m not sure this is inflationary enough.

  • 6months in, we’d be waiting 60 days between drops
  • If you need a bag to ‘play’ there are still only 125k bags generated in first 1,300 days

Those all seem like a long time in a nascent and growing community.

1 Like
#4

Thanks!

Would this contract type require gas fees for each minting?

Yes, this contract would require gas fees for each mint, as they generate new tokens on Ethereum.

If someone wanted to deploy to an L2 or sidechain and have the same mechanisms exist around a Loot contract hosted on those chains, they’d be able to do so easily, but there’s no interoperability planned.

Those all seem like a long time in a nascent and growing community.

That’s great feedback on the inflation rate. How quickly do you feel it should be able to get to 1,000,000 items?

#5

This is a wonderful idea. It gives OG Loot Holders a constant stream of income, while also lowering the barrier to entry for the general public

2 Likes
#6

FWIW, I think this is still very relevant.

mLoot having an unfair distribution (bagIDs content is known in advance https://github.com/Anish-Agnihotri/dhof-loot/blob/master/derivatives/temporal-loot/output/top-10k.json) makes it unsuitable as the basis for future game mechanics.

Spawning would maintain importance / relevance an item’s rarity.

4 Likes
#7

Thanks, yeah I was wondering how mLoot might change interest in this but I think you make a great point.

#8

the inflation rate seems like a good thing for governance to control

would let the loot community adjust for a rate they think will best accommodate the needs of the community

1 Like
#9

This sounds like a perfect model to me!

#10

Does this solve the problem of loots on secondary where items had been claimed on existing derivatives? If so, it is elegant and brilliant.

#11

To some extent yes, the bag will keep regenerating new items over time.

Once the cooldown’s effects become more prominent though there is still the risk of a seller withdrawing items right before selling, in which case the new owner wouldn’t be able to withdraw these again for a significant amount of time.

If the contract were to replenish on each transfer it’d make the inflation rate impossible to enforce, since bags could be transferred between two wallets of the same owner many times.

#12

I really like this idea… although, not sure how it mashes if we decide to incorporate mLoot into the ecosystem. Maybe mLoot and subsequent sets would require burn mechanism?

I like the intent of mLoot - however, I think the existing community should have taken a look at the item distribution prior, and had some sort of input to the rarity of items (or maybe a few unavailable). I think incorporating mLoot should be shelved and put to a vote later on (if somehow a community that collects mLoot forms while collecting NFT’s at a low barrier of entry, maybe it will force our hand (which would actually be great)).

Also agree to the unfair launch point made above - as I cherry picked a few katana’s and divine robes myself.

#13

yeah i don’t think mloot should be included based on the arguments above

#14

what about Item (for Adventurers)?

I think it should stay ERC1155 since that standard is specifically for semi-fungible tokens, which these are

I like the idea of Loot DAO having control over these options

#16

Okay I just woke up and caught up with all info but this is my hot take

Loot (Spawned) may be seen as the alluring 2nd tier of item to strive for in the Lootiverse. It is produced from the OG loot at set intervals as described above. mLoot would be a tier below them, and OG Loot a tier above.
When I say tier, this is the difficult thing to explain or understand. OG loot will be sought after for the fact you can produce Spawned (Loot) from it whereas you won’t be able to do that with mLoot nor a spawned bag.
I think all of this will become clearer with further products and building and discussion regarding what the other differences between the 3 Loot products would be, but I still believe in this being extremely importance in the Lootiverse.

1 Like
#17

I would support this

#18

I really like this. Are there any updates in terms of when something like this would go live? People have referred to Loot as building blocks in metaverse, but I think in some ways this idea would better serve that purpose.