tl;dr - Let’s create a framework for Loot and the crypto ecosystem, so that future projects have a standard to reference when determining airdrop, membership, perk eligibility.
Preamble
Hi. I’m a long-time crypto lurker/admirer since 2017 and seen very few moments like this (ETH, YFI). The beginning is innocent, creative, and then the enthusiasm dissipates into the usual price action, governance problems and tribal warfare. From an engineering perspective, I believe Loot has at least brought folks together and sparked this creative energy- let’s enjoy it and not obsess over the 69th fork.
Proposal
Borrowing inspiration from @dom @lotm and others, I propose that we kickstart an open-source framework to help projects determine a (synthetic) address’s “experience points”. In other words, how do you determine whether that address is eligible for future perks, add-ons, memberships?
Discussion
After digesting some of the discussion revolving around synthetic loots and enabling a widespread player base, a problem for Loot is how do you determine their eligibility for future add-ons? So far, for loot, it has been something like: If you hold a Loot token ID 1-8000, you’re able to claim:
Coincidentally, I believe this is a problem for sectors beyond just NFTs. For those familiar with areas like DeFi, a simple approach has always been to airdrop to wallets based on criteria such as:
- Interacting with contract at least once before a snapshot date (UNI airdrop 2020)
- Staked on a contract for
xnumber of days prior to, or within a date range (Star Atlas, Ellipsis veCRV)
I believe the criteria will only get more complex as the industry evolves. My initial thought is we need some sort of object or layer associated with the address. Here is where my lack of smart contract dev knowledge kicks in. I’m not sure which part of the stack this will belong in (smart contract level, node level, etc.), but from a high level, I’m imagining something like this to start:
So, that was a horrendous illustration. The main takeaways were supposed to be:
- The
Eligibility Metricobject associated to an address should be optional, and swappable for another object - There can be as many as
0...nobjects associated with an address. - An external contract can use
0...nobjects to determine eligibility. As over time, there will likely be different standards of evaluating eligibility.
Other related problems
Each of these problems are complex enough to be in their own thread - would prefer to keep their discussions to a minimum. Including:
- Best seed value(s) - To start, let’s just use the synthetic loot examples
- Metrics for eligibility - To start, let’s assume really simple metrics (ex. previous contract interaction).
- Transferability - I’m out of my comfort zone here, but I guess we’d need to mint an NFT and transfer that if we wish to save progress.
- Transaction costs - Cost of ETH and maximizing gas-efficiency
Help
Hoping to gather a subteam that is interested in reaching out across teams, learning, and collaborating on a positive-sum solution that can help all.
To anybody with a broader network: I feel like there must be other teams trying to come up with a solution for this. Can you help point us towards the right direction?
As for myself, I’m new to getting directly involved, and not sure what is the best way for me to contribute.
Strengths:
- Old-school, backend software engineer of about 6 years. More like a 0.5x engineer in crypto. But I’m somewhat confident in higher-level knowledge in the ecosystem.
- Previous career interacting with people. And I’m comfortable “reading the room”, bridging knowledge - I can speak to developers, normies, BTC, ETH maxis, blockchain-agnostics, the metric-driven TVL/FDV/cash-flow obsessed, traders, degen ape trolls bls ser - idk tho, cud be psyops?
- I can communicate and write - I guess?
Weaknesses:
- Bare minimum solidity, vyper and other smart contract or EVM knowledge
- No previous history of project contribution; no clout or network
- Overengineering (just being honest)
Lastly
I understand that this could have been solved or is already being addressed by another team. I’m not trying to be malicious or infringe on someone else’s hard work - I know how defeating it can be when your software is not used, or abused. And I understand this may be a thankless job.
If you’ve made it this far, thanks 
Teams that we may be able to learn from:
- Degenscore (metrics)
- Alchemist (crucible NFT)
- ETH Core Dev team if need to go lower-level
Related posts and inspirations:
https://loot-talk.com/t/proposal-for-gas-free-universal-loot-expansion-packs
https://loot-talk.com/t/synthetic-loot-viewer
https://loot-talk.com/t/synthetic-loot