Alert Icon

ATX DAO has migrated to a new forum

It's also important to note that if we implement a Nouns style membership like we are hoping to do, having incumbent members that worked on the organization with extra voting power would be beneficial for the organization since someone could accumulate as many ATX Nouns as they want.

Give me and @JacobHomanics a couple days to dig into the Snapshot Voting Strategies and then I'll write up a proposal!

Thanks for all the rigorous discussion!

512mace

Great to see security continues to be a priority.

This is why I love ATX DAO - I'm not the smartest person in the room! *

  • Please do not use for promotional purposes as it is a bit self-incriminating. :-)

I am putting Brennan's solution here as I improperly explained it on the weekly meeting.

  1. Axe the airdrop entirely
  2. Upgrade the current smart contract to allow for genesis/zilker NFTs to optionally upgrade to BlueBonnet artwork/metadata.
  3. Remove voting power from genesis (doesn't solve entirely, but helps to flatten voting weight).

This potential solution solves the voting weight problem in the short term (In order to solve it entirely would require something gitcoin passport). It also keeps things clean by still only dealing with 1 NFT Collection. It also removes the concerns around flooding the market with more (unneccesary) NFTs, thus helping out the treasury in the long run. Along with the concerns surrounding the airdrop being a legal issue if someone sells.

I don't think this is that "perfect answer", but at least one to add to the pool of options for the proposal.

    JacobHomanics Thanks for communicating this to the group!

    My main intent with the contract upgrade and meta data updates is to address a problem that was communicated to me roughly along these lines, "As an existing DAO member, I want to be able to customize my art using the minero tool and have the reflected on (one of) my membership NFT(s)".

    The solution that had been communicated to me about this was to include zilker and genesis members in an airdrop of the bluebonnet round tokens - leaving genesis members with 3 tokens, zilker members with 2 tokens, and bluebonnet members with 1 token. This conflates the "I want to customize my art" user need with "As an incumbent, I want increased governance weight".

    By introducing the possibility of upgrading the contract to allow for token URI updates (which would facilitate minero generated metadata being associated with a member's existing token) we fully decouple the desire to have the new customizable art from the more controversial distribution of governance weight and dilution of token supply.

    I see it as an optimal comprimise between "only bluebonnet members get an NFT" (no new art, no additional governance weight for incumbents) and "everyone should get a bluebonnet NFT" (everyone gets to customize / get new art, everyone gets additional transferable governance token).

    I believe that while this slightly increases the encapsulated complexity required for implementation (engineering lift to facilitate contract upgrade and process for updating token URIs for existing members), it significantly reduces systemic complexity associated with the "airdrop + 1 address 1 vote snapshot strategy" approach (no sybil attacks, no need for long term commitments to external software like gitcoin passport, no potential dilution of secondary market).

    Assuming the implementation for contract upgrades that @JacobHomanics and I discussed can be feasibly implemented by next Monday, I think we will end up with significantly fewer headaches over all by simply giving people the option to update artwork on existing NFTs rather then minting everyone a new one. However, this will mean that in order to get an NFT with the new artwork, a member will need to forfeit their original zilker art as the primary image linked within the metadata. That said, I believe we could still include the link to the original image in the token URI's metadata so that it is not lost for ever - it just wouldnt be displayable on applications such as opensea.

    A note on the snapshot strategy that @JacobHomanics mentioned. The intent of this is to achieve a "one member, one vote" system given the CURRENT unequal distribution of vote power. This snapshot strategy would NOT allocate voting power to wallets based on their ownership of a genesis NFT (token ids 1 through 25). This means that only Zilker and Bluebonnet NFTs would be used for governance and genesis members would not receive double voting power.

    Due to the increased manual work required on the engineering side, I believe that any proposal to go forward with this should allow for compensation of the contributor who prepares the contract upgrade and establishes a token URI update process for existing members - if they so desire.

    I should note, another option may be to airdrop bluebonnet to all members and then implement a voting strategy that ignores token ids 1 - 165 (genesis and zilker) for the purpose of calculating voting power

    It seems far simpler to just stay the course of the original Bluebonnet proposal and introduce a snapshot proposal to flatten the voting strategy.

    In that case, I would argue that a snapshot strategy which nullifies genesis and zilker token ids would be more aligned with the goal of having the new token airdrop not result in uneven governance weight than a snapshot strategy which implements "one address with atleast one token, one vote"

    However, it would remove the possibility of existing members sending their NFT to friends as a way of bypassing the application / purchase process to attain membership - which may or may not be desirable.

      I guess the biggest concern with that would be an excess of NFTs that could flood the market? Idk, I personally have no interest in dropping any of mine. Gotta have that cred. We also didn't have Genesis members selling after the last airdrop.

      I'd be curious to know the number of unique NFTs that were used to vote proposals. If we check each of the wallets that voted for an NFT, I expect we would see a lower number of potential airdrops.

        realitycrafter Ah yeah I see what you mean. That way its impossible for people who did not set their artwork and claim token to be left behind.

        If they do not claim can we autogenerate the metadata and airdrop? This may be non-trivial depending on the minero process

        According to my conversation with @clifton (feel free to express your thoughts here as well!):

        CAN DO:
        Mint new tokens with new metadata on existing smart contract.

        CANNOT DO:
        Upgrade existing smart contract.
        Change currently minted NFT metadata.

        The new proxy contract will necessarily need to be the owner of the existing NFT contract. On this proxy contract we can handle the authorization/verification of ETH addresses, payment and ensuring they get the NFT they created through minero. This would be done via merkle proof (we've used this for previous rounds but it would be a little more complicated since it would need to also verify the nft metadata).

        If we wanted, we could offer a trade-in mechanism for burning an old nft in exchange for a new one. Therefore there would basically be two public functions: mint(...) and tradeIn(...).

        12 days later

        This vote ends in a couple hours. It really seems like a vote for the identity of the DAO.

        Are we a pyramid structure based on seniority or a relatively flat organization with a couple founding members slightly elevated?

        I've been thinking about this issue for a while and I've come to the conclusion that extra NFTs / voting power based on tenure is a pretty crude method of distributing voting power. If we were to really lean into REP as a way of tracking involvment in the org, we could use it as a multiplier on voting power. This would give new members a way of building additional voting power through their contributions.

        With this in mind, I am changing my vote to burn exchange instead of airdrop.

        Powered by: FreeFlarum.
        (remove this footer)