Proposal 54 (Q1828)
From Nouns Dev
A Nouns proposal.
| Language | Label | Description | Also known as |
|---|---|---|---|
| English | Proposal 54 |
A Nouns proposal. |
Statements
0
0 references
Nouns Tech Grants
0 references
27
0 references
41
0 references
54
0 references
11 April 2022
0 references
We read this one, and you know, thought it was pretty good.
0 references
Verbs
0 references
11 April 2022
0 references
These two engineers are my partners from Verbs so feels right to abstain. I am very excited for them to work on Nouns tech!
0 references
3
0 references
2
0 references
4
0 references
162.5614
0 references
162.56
0 references
1. is that new subgraph url using the contract addresses in the branch?-2. bumped-3.1. which version number do you want it to be? 0.3.0?-3.2. should the @nouns/sdk dependency be updated to ^0.2.0 ?-4. π-5. & 6. π
The question was answered in the direct replies:--1. Yes, the new subgraph URL is using the contract addresses in the branch.-2. Bumped.-3.1. The version number should be 0.3.0.-3.2. The @nouns/sdk dependency should be updated to ^0.2.0.
0 references
2. Away from my machine until tn, but figure it'd be easiest to merge all art into a single file, appending the 8/8 additions to the existing v1 art. Any obvious reason that's a bad idea?
0 references
<@378904401290592258> again will double check the root cause of the not being able to vote issue but if it _is_ an ABI difference issue ... that probably wouldn't manifest in prod right as we're not changing the nouns token contract?
0 references
<@378904401290592258> maybe I misunderstood something earlier so trying to confirm ... is the submit vote button always / sometimes / never disabled for you when it should be?
0 references
<@378904401290592258> we need to deploy the new contracts first, right?
Yes, the new contracts need to be deployed first.
0 references
<@378904401290592258> (when you have some time, know it's late) would love your thoughts on https://deploy-preview-585--nouns-home.netlify.app/--think I've fixed the issues you flagged / tested all the cases I could think of but would love a second pair of eyes. If it looks good, maybe we do one more full mock of the upgrade and then go for it?
0 references
<@701029092547493888> thanks for setting this up ... one question ... is the plan to refer to the v2 contracts as v1 (at least maybe in the context on the webapp)? Asking because elad mentioned deploying v1 contract earlier and the Etherscan of the contract marked in the config as `nounsDaoLogicV1` seems to be the v2 contract? --Wonder if maybe I missed something (this also could just be a dumb question because it's still pretty early for me haha)
The question about whether the plan is to refer to the v2 contracts as v1 in the context of the webapp was not directly answered. However, davidbrai#5671 mentioned that it doesn't make a significant difference how they are referred to in the webapp and suggested that brianj#3816 could decide what's better.
0 references
<@804065259383685161> does this summary make sense to you?-and do you think the high priority issues are fixed and ready for another full upgrade cycle?
0 references
<@804065259383685161> getting this compilation error, any idea why? looks like you changed some stuff around there a couple months ago:--```-β Compile subgraphERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.-- ? fromHolder.delegate.toString()- ~~~~~~~~~~~~~~~~~~~- in src/nouns-erc-721.ts(171,7)--ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.-- ? toHolder.delegate.toString()- ~~~~~~~~~~~~~~~~~- in src/nouns-erc-721.ts(174,7)--ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.-- let toHolderDelegate = getOrCreateDelegate(toHolder.delegate ? toHolder.delegate: toHolder.id);- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~- in src/nouns-erc-721.ts(178,46)-```
0 references
<@850478993463443487> <@813421644298321961> regarding changing the vetoer, what are your thoughts on allowing *only* the DAO to change the vetoer address?-* it moves the power of changing vetoer from the vetoer to the DAO-* in case of a malicious proposal to change the vetoer, the vetoer can veto it--wdyt?
0 references
<@850478993463443487> any idea why the netlify build is failing on this PR? https://github.com/nounsDAO/nouns-monorepo/pull/589
0 references
<@850478993463443487> changed the `tokenAmountNeededAndETHPayout` as you requested.-see here: https://github.com/nounsDAO/token-buyer/pull/5--if it matches what you needed, feel free to merge or approve
0 references
<@850478993463443487> do you know how we can we add a nounsbot to the nounish server?
To add a nounsbot to the nounish server, you need to deploy the code from https://github.com/nounsDAO/nouns-monorepo/tree/master/packages/nouns-bots and point it at your webhook token & ID. A simpler path should be available in the not-so-distant future.
0 references
<@850478993463443487> do you know if the new heads are planned to use the existing color palette or will there be a new one?
The new heads are planned to use the existing color palette, as mentioned by solimander#7468.
0 references
<@850478993463443487> do you think descriptor-v2 and vote-refund are ready for implementation?
Yes, solimander#7468 believes that descriptor-v2 and vote-refund are ready for implementation.
0 references
<@850478993463443487> do you think we're ok to merge the V2 branch into master? (once conflicts are resolved)
Solimander#7468 wants to have one final look-through before merging the V2 branch into master, but they believe it should be ready to merge very soon.
0 references
<@850478993463443487> how would you like to do the proposal? would you run the task or do you want to delegate us a noun?
Solimander#7468 mentioned that they can delegate a noun in response to davidbrai#5671's question.
0 references
<@850478993463443487> not sure if you saw this, could you reply when you get a chance? https://github.com/nounsDAO/nouns-monorepo/pull/557#issuecomment-1236567138
0 references
<@850478993463443487> regarding the subgraph for token-buyer:-should it be added to the existing nouns subgraph or to a new one?-was thinking it makes sense to add to the nouns subgraph so that it under the same billing mechanism?
0 references
<@850478993463443487> should I go ahead and merge the tech-spec branches for them?
Yes, go ahead and merge the tech-spec branches for them.
0 references
<@850478993463443487> should I try to merge from master to resolve the typechain issues?
Yes, you should try to merge from master to resolve the typechain issues.
0 references
<@850478993463443487> we are ready to put the upgrade proposal on chain.-next steps:--1. deploy LogicV2 contract to mainnet-2. create proposal: need 2 votes for that. do you want to do it, or do you want to delegate one vote me?--wdyt?-anything else you'd like to test or check?
The next steps for the upgrade proposal are:--1. Deploy LogicV2 contract to mainnet.-2. Create a proposal, which needs 2 votes. Solimander#7468 has delegated one vote to davidbrai#5671 at the address 0x05A286e5165D72823A749B00b009a2aF0dc36Ff7.
0 references
<@850478993463443487> we deployed the updated NounsDAOLogicV2 contract (only linear coefficient) to rinkeby (https://rinkeby.etherscan.io/address/0x5D24DA2edf5e90dB97521de276Ff9AEaAFB9628e#code)--what do you think would be the best way to set up the env on rinkeby?-we considered upgrading the current dao contract, but we'll probably have storage issues because the DynamicQuorumParams struct is now smaller.--the alternative is to deploy from scratch, which would probably be cleaner.--do you have thoughts on what's better?--if we deploy from scratch, should we just use `yarn task:deploy-and-configure` ?
The best way to set up the env on Rinkeby would be to deploy from scratch using `yarn task:deploy-and-configure`.
0 references
ah, interesting-how is netlify messing up the UI determining prop state?
0 references
another question:--when calculating the right bound of the row (`this._width - rects[rects.length - 1].length`), if I'm not mistaken, this lands on the pixel *after* the last one.-e.g if last rect has length 1, and width is 32, then `right` will be 31, which is the last pixel when counting zero based.-is that the intention? because my understanding was that the bounds within the colored area
When calculating the right bound of the row, it may have been to avoid a `- 1` when looping over the rects in `MultiPartRLEToSVG`. If that's not the case, it can be fixed. The updated bounding box code makes the encoder less confusing and easier to read.
0 references
any appetite to create a subgraph for the token buyer?
There is an appetite to create a subgraph for the token buyer. Elad#6192 mentioned that it's a great idea and they will add it to their to-do list.
0 references
anything you think we should do before putting the proposal on chain?
Before putting the proposal on chain, it is suggested to create a HackMD document with the proposal description, finalize the art additions, and ensure Rinkeby testing is sufficient. The same flow as last time can be followed: passing over the description, delegating to the same address, and putting it on chain.
0 references
are you sure it's because of the gas issue or because the seed tuple wasn't parsed correctly?-when I call tokenURI on the NounsToken with new descriptor on rinkeby I am getting a result: https://rinkeby.etherscan.io/address/0x59D3356299432c58c80603316786868479753C23/5#readContract
Yes, it seems the issue was not because of the gas issue but because the seed tuple wasn't parsed correctly.
0 references
are you working on my little repo or in the nouns repo?
Solimander is working on your little repo, and they have been added as a contributor to push their changes.
0 references
asking a probably stupid question just to confirm something for myself:--Is the newly updated hosted service indexing the contracts you pushed this morning? Asking because I no longer see the upgrade props you and I made today in the results--```--{- data: {- proposals: [- {- id: 1,- description: # test\n\ntest- },- {- id: 2,- description: # test\n\nest- },- {- id: 3,- description: # asdf\n\nasdf- },- {- id: 4,- description: # sdfg\n\nsdfg- }- ]- }-}--```--Again, could just be some side effect of the contract upgrade I did around the same time or something so like I said sorry if I'm being dumb π
0 references
but to the DAO we see them as fungible?
Nouns are treated as fungible within the DAO, and they are essentially like ERC1155 tokens. The issue with batch transfers arises because they are ERC721 tokens, so workarounds are needed. An allowance-based batch transfer contract was created to make the process more gas-efficient and auditable. Each pod can pay for their own individual allocation and choose how many to transfer.
0 references
current agenda ---β’ is it worth adding support for a log curve? is it likely that this curve will be used in production?-β’ should the dynamic quorum function take βabstainβ votes into consideration?
0 references
did the heap out of memory come from hardhat node or the js client?
The heap out of memory issue came from the hardhat node.
0 references
does that mean we would have 1 proposal instead of 2 proposals?
Yes, in the conversation, solimander#7468 suggests keeping 2 proposals instead of 1 proposal. They mention that the new part indexes will be present in the frontend but unused until the art is added at the contract level.
0 references
does the CI spin up a frontend? do I need to open a pull request for that?
Yes, you need to open a pull request for the frontend. The CI does not spin up a frontend automatically.
0 references
do you remember the parameter name?
Initial optimizations of the inflate library dropped the gas usage from 192,236,349 to 110,965,924, which is mostly due to removing overflow/underflow checks. The while loop inside `_codes` does about 20,000 iterations, which is a significant gas burner.
0 references
do you think it's a change worth doing for DAOLogicV2?
0 references
do you want to edit the description in the proposal hardhat task?
Yes, they want to edit the description in the proposal hardhat task. Solimander#7468 mentioned they want to provide a little more context around the upgrade and art edits.
0 references
gm π --1. the rinkeby environment is used when testing PRs. probably not worth the time upgrading the old rinkeby deployment (no useful state). update the rinkeby subgraph url in the webapp to https://api.thegraph.com/subgraphs/name/nounsdao/nouns-subgraph-rinkeby-v5 and we should be all set-2. can you bump to `0.2.0` instead? I can publish once complete-3. yes, `@nouns/assets` should also be bumped. I can publish that to npm as well-4. there's a misconfiguration that causes the former to fail. will fix that soon. we're good as long as the latter works-5. we'll merge to `staging`, do a final round of testing, and then merge to `prod`, which will auto-deploy to production
QUESTION: Is there a timeline for the new Nouns artwork for 8/8?--ANSWER: 8/8 is the anniversary, and the plan is for new artwork to be added _by_ then. However, proposal 114, to merge the descriptor upgrades, will pass by a week from now. The new traits are being decided via the <#931247256470953994> channel and haven't been completed yet. The plan is to decide/vote by the end of the month to give a week to add smoothly, etc.
0 references
gm <@618796826577076245>! have you had a chance to look into the JS heap issue?
0 references
gm <@618796826577076245>!--we've been talking about removing the test coverage task from the contracts CI-we feel like we're not gaining much from it, while it's costing us a lot of CI minutes--I believe you're a proponent of coverage, so I wanted to get your updated take on it-do you have any objection to removing the coverage run from our CI?
0 references
Gm <@804065259383685161> -Now that the upgrade prop is cooking, let's get ready to merge your webapp PR?
Yes, that's correct. The DAO sees the Nouns Vision Glasses tokens as fungible, meaning they don't place specific importance on individual token IDs and want to transfer them in batches.
0 references
gm <@804065259383685161> -we deployed a new version of the LogicV2 contract on rinkeby. it is without a quadratic and offset param.--we also deployed a frontend forked from your branch: https://deploy-preview-485--nouns-home.netlify.app/--the struct returned by `getDynamicQuorumParamsAt` is a bit different now:--```-struct DynamicQuorumParams {- /// @notice The minimum basis point number of votes in support of a proposal required in order for a quorum to be reached and for a vote to succeed.- uint16 minQuorumVotesBPS;- /// @notice The maximum basis point number of votes in support of a proposal required in order for a quorum to be reached and for a vote to succeed.- uint16 maxQuorumVotesBPS;- /// @notice The dynamic quorum coefficient- /// @dev Assumed to be fixed point integer with 6 decimals, i.e 0.2 is represented as 0.2 * 1e6 = 200000- uint32 quorumCoefficient;- }-```--so it will require some small change on the front end. could you help us with that?
Yes, brianj#3816 has made the changes to support the linear function for Dynamic Quorum on the frontend. They have pushed the changes in this pull request: https://github.com/nounsDAO/nouns-monorepo/pull/485
0 references
gm <@850478993463443487> and <@804065259383685161>!--wanted to check in re:webapp for V2-looks like this is the PR that's awaiting approval and deployment, right? https://github.com/nounsDAO/nouns-monorepo/pull/594--when do you think we will be able to deploy to prod?-π
The webapp for V2 was deployed after the mainnet subgraph was tested on staging and everything looked good. The deployment occurred following the auction close on the same day as the conversation.
0 references
gm <@850478993463443487> before merging the descriptor v2 branch to master, we would like to make sure we're aligned on a few last points:--1. rinkeby contract addresses: not sure if the rinkeby environment is being used or not. If it is, then maybe it's important to use the new contracts. or if the existing contracts already have some useful state, maybe they need to be upgraded with a proposal. how should we move forward here?--2. bumping nouns-sdk: we bumped the version from 0.1.6 to 0.1.7 after changing the Image class. do you want us to publish it to npm also? I guess we need permissions for that?--3. what about nouns-assets? should it also be bumped?--4. want to make sure the webapp works correctly against mainnet. when browsing to https://deploy-preview-499--nouns-home.netlify.app/ we're seeing 403 errors when connecting to alchemy. https://deploy-preview-499--nouns-testnet.netlify.app/ seems to work fine though.-what's the difference between these two deploy previews?--5. anything else we should do before merging to master?--6. what should we do after it's merged to master? is it automatically deployed to nouns.wtf or is there a deployment branch for that? should we ask brian to help here?--also available for voice sync if you prefer
The question was answered in the context:--1. Rinkeby contract addresses: Update the Rinkeby subgraph URL in the webapp to https://api.thegraph.com/subgraphs/name/nounsdao/nouns-subgraph-rinkeby-v5.--2. Bumping nouns-sdk: Bump the version to 0.2.0, and solimander#7468 will publish it to npm.--3. Nouns-assets: Bump the version to 0.3.0, update the @nouns/sdk dependency to ^0.2.0, and solimander#7468 will publish it to npm.--4. Webapp working correctly against mainnet: There's a misconfiguration causing the 403 errors, but it's fine as long as https://deploy-preview-499--nouns-testnet.netlify.app/ works.--5. Before merging to master: Merge to staging, do a final round of testing, and then merge to prod, which will auto-deploy to production.--6. After merging to master: It will be automatically deployed to nouns.wtf.
0 references
gm <@850478993463443487>, do you think we can merge the vote refund branch into the dynamic quorum branch?
Yes, the vote refund branch can be merged into the dynamic quorum branch. Solimander#7468 mentioned that it is good to merge after doing one more quick pass.
0 references
Got it-Just making sure we're talking about the same thing, I was suggesting the deployment of V2 with the existing art
Yes, the deployment of V2 with the existing art was discussed and confirmed in the direct replies:--solimander#7468: here are the art fixes that should be included in the first proposal: https://github.com/nounsDAO/nouns-monorepo/compare/verbs-descriptor-v2...soli-art-fixes?expand=1-solimander#7468: yes, these would be fixes to the existing art
0 references
got it. So in the prod deployment we probably want explicitly in the address config for example `nounsDaoLogicV1: 0x...., nounsDaoLogicV2: 0x....` correct? To support both?
In the prod deployment, it is suggested to have explicit address configurations like `nounsDaoLogicV1: 0x...., nounsDaoLogicV2: 0x....` to support both versions. However, the logic address is not really used anywhere, as the proxy is mainly loaded.
0 references
Has someone ever considered a form of quadratic voting in a fork of Nouns?
Yes, someone has considered a form of quadratic voting in a fork of Nouns. However, it was mentioned that for quadratic voting, a proof-of-humanity system is needed. Gitcoin was brought up as an example, as they use a system called Gitcoin Passport for proof of humanity.
0 references
have started doing some experiments-unfortunately looksrare & rarible are really bad at telling you why they're not showing the data, especially rarible--I deployed a token that spends gas and returns a nouns svg in return-opensea shows token up to 1000M gas at least: https://testnets.opensea.io/collection/gassy-token-v2-looksrare also showing up to 1000M gas, but then stopped rendering new tokens with lower gas, so I'm waiting to see if it fixes itself: https://rinkeby.looksrare.org/collections/0x033b54336bbc3b0885ca84c14e0d74288ee2ab89-rarible showed up to 400M gas, but is now showing just the metadata and not the image, even though it showed the image a few minutes ago. also going to see if it fixes itself--will mint a few more tokens in the 100-1000 M range and check the links in a few hours
Based on the conversation, it seems that the current plan is to move forward with RLE + batch SSTORE2 + DEFLATE. The issue with Rarible and LooksRare is still being investigated, but the tests conducted so far indicate that it should be possible to proceed with the proposed solution.
0 references
hey, <@303004182129147905> made an interesting suggestion: that we give the veto a programmatic expiration date. what's nice about this is that if veto expiry is passed as a proposal it would be up to the dao to extend the veto, and the current vetoer couldn't prevent the expiry. it also covers the case where the veto falls into the wrong hands, the dao would only be held hostage until expiration. am i missing any obvious downsides here?
The main downside of giving the veto a programmatic expiration date is that if the DAO is delayed at extending the veto expiration, it creates a window of opportunity for a malicious proposal. This is a concern as long as there aren't additional mechanisms in place, such as defense against last-minute vote swings. Setting the expiration 1-2 years into the future could potentially work, but more defensive mechanics would need to be in place.
0 references
hey <@804065259383685161> I have a small testing feature request--can we please change the bidding UI so that in testnet mode bids can be lower than 0.01 ETH?
0 references
Hey <@804065259383685161> !--We updated the contract code to a simpler quorum function. It's only linear now.--Does your UI code need any updating to support the new function?
brianj#3816: Yes it will need some but shouldnβt be too bad-brianj#3816: Basically just swap out a function or 2-brianj#3816: And hope it doesnβt break anything lol
0 references
hey <@850478993463443487> -been trying to deploy our branch all day with partial success--deployments to Rinkeby are stuck-got it deployed to goerli, but OpenSea seems to be acting up on networks that aren't Rinkeby--do you know if it's reasonable to expect to test on OpenSea on goerli, or is Rinkeby the only option?
0 references
hey <@850478993463443487> can you please review the current state of hardhat->foundry migration? https://github.com/nounsDAO/nouns-monorepo/pull/589--we're thinking to do this in small incremental PRs, this one being the first --π
0 references
hey <@850478993463443487> -in preparation for the descriptor tech spec, we created a spike branch that reuses the work you've done, and further clarifies the smart contract design--it is not meant to pass tests or run in any way, just to compile so we can make sense of the contracts direction--assuming this implementation, this is how I might go about creating a fork like fast food (pseudo code):--- fastFoodRenderer = deploy ExampleForkFastFoodSVGRenderer(nounsRenderer to reuse)-- art = getNounsDeployedArtContract()-- descriptor = deploy new Descriptor(art, fastFoodRenderer)-- seeder = getNounsDeployedSeeder()-- deploy NounsToken(β¦, descriptor, seeder, β¦)-- deploy a new auction house-- deploy a new Timelock and DAOProxy, reusing Nounsβ deployed DAOLogic---can you please take a look and share your feedback?--https://github.com/nounsDAO/nouns-monorepo/compare/master...verbs-descriptor-v2-spike--P.S. some lower-priority questions we wanted to listen to your thoughts on:-* isDataURIEnabled: noticed it was removed in your branch, but we thought it could be nice to keep-* NFTDescriptor: could it make sense to convert it into a contract? we find it generally more convenient to work with contracts, and not sure of the reasons it's a library atm-* Inflate: it's currently a private library; curious for your thoughts on whether it should become a public library or a contract?-* `ISVGRenderer.Part.palette` is a pointer to an SSTORE contract: we were thinking to experiment with it being `bytes` similar to the `image` part, but thought maybe you explored that and had reasons to keep it as a pointer, like gas savings? the benefit of such a change is mostly a design consideration, i.e. making SVGRenderer unaware of storage sources, thus not imposing such a constraint on its users
The question was about feedback on the proposed implementation and some lower-priority questions. The direct replies from solimander#7468 provide feedback on the implementation and address the lower-priority questions. Here's a summary of the answers:--1. Regarding trait retirement, it's better to leave it out of the implementation until there's consensus on how traits should be selected for retirement.-2. isDataURIEnabled can be added back in for the sake of forkers.-3. NFTDescriptor can be converted into a contract if preferred, as there's no strong reason for it to be a library.-4. For Inflate, it's worth looking into gas implications before deciding whether to make it a public library or a contract.-5. Changing ISVGRenderer.Part.palette from a pointer to bytes could be a reasonable solution, and it's worth looking into.--Additionally, there are some discussions about issues with the frontend and subgraph, but they are not directly related to the original question.
0 references
Hey <@850478993463443487> is FOMO deployed with the new art?
Yes, FOMO is deployed with the new art.
0 references
hi all, we have a potential solution we are exploring for being able to pay builders with stables (e.g. DAI/USDC)-this can be a pretty significant change, so we want to get all feedback before we start implementing.-in the visual you can see a simplified explanation of how it will work for the builders (proposers).--do you think this is a good solution for nouns dao?-do you see any issues?-do you have other suggestions?-any questions whatsoever?--for more technical spec: https://github.com/nounsDAO/nouns-tech/blob/payment-in-stablecoins/payment-in-stablecoins/README.md
The proposed solution for paying builders with stablecoins (e.g., DAI/USDC) involves creating a USD buffer that the DAO can use to pay builders directly in USD. If builders receive IOU tokens instead, they can easily redeem them for stablecoins by clicking the redeem button. The DAO can choose a buffer size and continually re-supply it. If a builder needs more funds sooner than the DAO can swap, the mev/arb bots will work to swap the rest. The community seems to agree that this solution is a good fit for Nouns DAO, as it improves the builder UX and allows for trustless swapping of ETH for stablecoins.
0 references
Hi. Reading the prop Iβm just curious to know more on the gas reimbursement piece. Is this if you vote opposite of what happens? Was looking for clarity on why the DAO would reimburse gas here but couldnβt find it. Thanks!
The gas reimbursement piece is simply an ETH refund for the cost of voting, no matter which way you vote. This is done to encourage more nouners to vote.
0 references
hmmm, what's the gas usage for multi-rle sstore2 if unlimited contract sizes are allowed?
The gas usage for multi-rle SSTORE2 with unlimited contract sizes is not directly provided in the conversation. However, it is mentioned that using Deflate + SSTORE + Multi-RLE results in a gas consumption of 14,368,017, which is a significant reduction compared to the baseline.
0 references
how are you thinking about batch decompression in the contracts?
Batch decompression in the contracts hasn't been given much thought yet. There is a 17% savings in compression when using multi RLE + batch deflate compared to multi RLE + deflate, but it's not clear if the added complexity is worth it. There is also a discussion about gas savings from writing fewer pointers and the possibility of optimizing without batch compression. The current gas limits from providers like Infura and Alchemy may not be an issue for decompressing 24K bytes.
0 references
how did you imagine nouns-contracts consuming from nouns-assets?
It would be great if nouns-contracts could consume the art from nouns-assets directly, rather than keeping two copies. However, this was initially avoided due to a circular dependency issue. Versioning in nouns-assets, which could export both the individual & merged art, might be a solution, but it's not something that necessarily needs to be completed now.
0 references
how does that help with this heap error?
The heap error might be related to the way `estimateGas` is implemented. It was suggested to try using a transaction approach instead, pointing at a local Anvil node for better performance, and using the gas-optimized version of inflate.sol. The updated gas was 111,930,036, which is in the expected range. However, the issue with the vertical RLE still needs further investigation.
0 references
I don't know; currently all heads as one chunk exceeds the contract size limit, so I never got it deployed and stopped there--wanted to wait for some feedback--if it's an important flavor to explore, we would need a bit more time to change the code to break up image types that exceed the limit into a few chunks --do you want us to invest in that?
The current approach of using deflate might not be ideal due to the high gas usage for reading `tokenURI`. It is suggested to measure the gas of reading `tokenURI` to assess the gas limit risk and test multi-directional RLE with SSTORE. The team is also considering other options, such as using a local Anvil node for better performance.
0 references
I'm not so familiar with the Nouns Vision Glasses tokens and the allocation to the DAO.-Looks like they are ERC721.-And I see the treasury holds 500 of them: IDs 751-1250--so far correct?
The Nouns Vision Glasses tokens are ERC721, and the treasury holds 500 of them with IDs 751-1250. In the DAO, they are seen as fungible, and the goal is to transfer them in batch without placing specific meaning to specific IDs.
0 references
I'm seeing some weird behavior, when running hardhat verify plugin, it sets the `linkReferences` of the `NounsDescriptorV2.json` to `{}`-have you experienced this in the past? <@850478993463443487>
0 references
initial spec for the descriptor v2: https://github.com/nounsDAO/nouns-tech/tree/verbs-descriptor-v2/descriptor-v2--<@850478993463443487> when you have a few minutes, could you please review and give feedback?
The question was about reviewing and giving feedback on the initial spec for the descriptor v2. The conversation includes feedback from solimander#7468, who mentions that the spec looks good and incorporates the ideas discussed. They also point out that the RLE encoding should mention the limitation of each tuple to a length of 255 and that if the run-length is greater than 255, it must be broken into multiple tuples. Davidbrai#5671 updates the spec accordingly. Other community members also provide their opinions on the spec.
0 references
Is it possible to get a βcryptoeconomicβ audit of dynamic quorum before DAO governance logic is changed? Of all the paths to improving governance, why are we only testing one? How can we be sure it has no unintended consequences?
0 references
Is NO too strong with dynamic quorum? The default case for any governance is that it does nothing (ie funds sit in treasury unless actively moved). I think Joshua raised this case. Can we be sure with the right parameters that the power of NO comes in only when a prop is contentious?
It depends on how you define contentious, but that puts us back in the land of curve tuning. The right parameters would be needed to ensure that the power of NO comes in only when a proposal is contentious. There is a concern about voter confusion between voting NO or ABSTAIN if they want the proposal to fail, and this confusion may not be healthy for the DAO.
0 references
I started looking at the images in: https://github.com/nounsDAO/noundry/tree/8-8-trait-candidates/traits-I don't know if you still plan to do any changes there, but wanted to start working on the encoding.--while encoding the images, it seems like there's a new color that wasn't in the palette before: #b91b43, coming from head-couch image-our working assumption was that no new colors would be added to the palette.--1. do we want to change that and add a new color? (will require some more testing)-2. or do we want to change the color in the image?--awaiting your input <@850478993463443487> <@557727542149120010> <@245856432107290624>
Yes, it's purposeful to add the color #b91b43 back in, as it was deleted in the latest update but is now being used for the couch. However, there is some uncertainty about whether the couch should be colored red.
0 references
is the new subgraph backwards compatible with the existing production frontend?
Yes, the new subgraph should be backwards compatible with the existing production frontend. As elad#6192 mentioned, they only made additive changes, so there shouldn't be any issues with compatibility.
0 references
is there any reason the abi for the nouns _token_ would have changed as a result of this deployment?
0 references
Is there a simulator or model where we can take a look at the raw behavior of the function independent of implementation? It would be nice to play around with it in a browser or spreadsheet to understand the outcomes of different levels of contention
There is a simulator in the form of a Google Spreadsheet where you can take a look at the raw behavior of the function independent of implementation. You can find it here: https://docs.google.com/spreadsheets/d/1trmtpgSLx8cfm-wD79mQWyh2y_GwW3X7f2rEnSWJ3AM/edit#gid=999443709.
0 references
is there a way to see which commit the deploy-preview is showing?
0 references
is the risk of a malicious vetoer real?--can you say more about how that might happen?
The risk of a malicious vetoer is considered real but with a very low probability. It could happen under adversarial conditions in the home jurisdiction of the foundation or if the foundation multisig gets hacked. The risk increases with the scale of the DAO.
0 references
is this what you meant? https://github.com/nounsDAO/token-buyer/compare/v1-queue-add-available-eth?expand=1
0 references
I think it can make a voter wonder: what would stop this proposal more? if I abstain or vote no?
0 references
I think we have a lot to gain now from people having time to move their delegates in preparation for specific votes-the DAO has grown and people have certain others they trust depending on the proposal content--maybe worth reconsidering?
0 references
I understand your idea as just making sure `tokenAmountNeededAndETHPayout` takes into account the buyer's ETH balance, so it would use `min` on balance and the ETH amount that correlates with token amount needed--in short, the function should output amounts you can go right ahead and buy/sell, knowing it won't fail due to insufficient ETH balance--is that right?
Yes, that's right. The function should output amounts you can go right ahead and buy/sell, knowing it won't fail due to insufficient ETH balance.
0 references
I wanted to bring up a concern on proposal 114:--proposal 114 (https://nouns.wtf/vote/114) proposes to change the appearance of some nouns - most of the changes are unnoticeable (like bug fixes), but some are actually noticeable, in particular the colors of some glasses.--why is this a problem?-reason 1 (reliable appearance): nouners may be planning some branding, generating some memes, paying designers, making stickers, etc - it's annoying to have to account for the re-design some of these features-reason 2 (kind of precedent): same as above, but now nouners know that their noun can change (and change is unclear here, will we change colors? content? taco ingredients?), and when there is change people are less like to build on top of things that aren't reliable--potential ways forward-1) philosophy 1: accept anything can change-2) philosophy 2: accept anything can change, but only from now onwards (legacy nouns will still look the same)-3) philosophy 3: vote against proposals that change nouns, since it make it difficult for others to realy on these appearances and we don;t want to set a bad precedent--does everyone see what I see?
The concern raised in the question is about proposal 114, which proposes to change the appearance of some nouns, including the colors of some glasses. The user mentions that this could be a problem due to the potential impact on branding, memes, and other design elements, as well as setting a precedent for future changes.--In the direct reply, davidbrai#5671 mentions that there seemed to be support for this change in the Discord and provides a link to the relevant conversation. They also suggest that if the user doesn't think it's a good idea, they can vote against the change and bring it up in the appropriate channel.--The conversation does not provide a definitive answer to the concern but acknowledges the potential issues and suggests that users can vote against the proposal if they disagree with the changes.
0 references
Just catching up on the thread. I'll take a look at the PR but looks like we need to swap some assets?--Is there a timeline for the new Nouns artwork for 8/8?
The timeline for the new Nouns artwork for 8/8 is that it is planned to be added by the anniversary date. However, the new colors will be fixed immediately after Proposal 114 passes, while the new traits won't be added yet because they are still being voted on.
0 references
Just following up again on this. I've submitted a new build containing the art asset fixes to Apple for review (build includes a couple of other fixes). This will hopefully go out in an update later today. Also wanted to check in on the 8/8 Nouns assets. Any word? <@245856432107290624>
0 references
Just looking at that, does it feel like that should be a passing prop?
0 references
keeping all these versions in nouns-assets, and nouns-contracts importing the separate jsons from nouns-assets?
0 references
looking for implementation feedback or just high-level thoughts?
0 references
Looks great!-Only thought: should we further clarify that a new 8/8 art prop is coming up (and this isn't that)?
0 references
looks like it's ok even when pending, perhaps it's a delay with subgraph indexing?
0 references
maybe you would like to beef up the proposal text in `populate-descriptor-via-proposal.ts` ?
0 references
ok I am ready to submit test proposals:--1. submit the upgrade to V2-2. submit another proposal while we're still on V1-3. execute the upgrade to V2-4. check that the prop from step 2 behaves as expected-5. submit a new prop and expect to see V2 UI--however, I don't want to do it yet bc I don't want to mess up the reproduction of the state right now with prop 16 (see above)--please lmk <@804065259383685161> when you know what that's about and then I'll go ahead and run this test flow--thanks!!
0 references
ok, so I can deploy a front end from master branch pointing to the same contracts,-do upgrade to V2-and then use the new webapp version--makes sense?
Yes, deploying a front end from the master branch pointing to the same contracts, upgrading to V2, and then using the new webapp version makes sense as a temporary solution. However, it is important to ensure the frontend seamlessly handles the upgrade before mainnet.
0 references
On the iOS side we're going to be pushing an update in the next couple days with the asset fixes. π--Any word on the new Noun assets for the 8/8 anniversary? We need some lead time to update the app and have it ready for 8/8.
Any word on the new Noun assets for the 8/8 anniversary? We need some lead time to update the app and have it ready for 8/8.--Goldy#0420: i think we're currently aiming to lock assets in by friday so they can be tested...
0 references
open question: should abstain make any adjustments to the quorum? for example: we've seen people vote abstain instead of no in a number of occasions (https://nouns.wtf/vote/72, https://nouns.wtf/vote/86) which signals some form of contention but wouldn't affect DQ
0 references
past votes have been around 110K, so anything above 133K should prob be ok?
0 references
question: was this right after prop creation?
0 references
quick update what we're working on:-* Descriptor V2: hoping to deploy it in time for the 8/8 art update! it makes art deployment ~5x cheaper, and makes it easier for forks to reuse existing art (from Nouns or any other fork)-* Gov V2: the big change is dynamic quorum (more against votes -> higher quorum); adding <@361204440499486720>'s vote refund feature; might add a mechanism that defends against last-minute prop swings - this one is still in design led by <@850478993463443487> --Specs:-* Descriptor: https://github.com/nounsDAO/nouns-tech/tree/main/descriptor-v2-* Dynamic Quorum: https://github.com/nounsDAO/nouns-tech/tree/main/dynamic-quorum-* Vote Refund: https://github.com/nounsDAO/nouns-tech/tree/main/vote-refund--Code:-* Descriptor: https://github.com/nounsDAO/nouns-monorepo/pull/499-* Quorum: https://github.com/nounsDAO/nouns-monorepo/pull/438--What's next:-* Descriptor V2: finish code changes, get into code review and testing with more people involved (should happen next week)-* Gov V2: we'll start coding the vote refund once descriptor is stable; then hopefully we'll have a design for last-minute voting to work on; then get this big release audited and tested by more people; the quorum function coefficient discussion is still open as well, TBD closer to audit time--<@701029092547493888> anything to add/edit?
The team is working on Descriptor V2, which aims to make art deployment ~5x cheaper and easier for forks to reuse existing art. They are also working on Gov V2, which includes dynamic quorum, a vote refund feature, and possibly a mechanism to defend against last-minute prop swings. The Descriptor V2 is in the code review and testing phase, while Gov V2 is still in development.
0 references
roughly 3GB of heap usage when I use `process.memoryUsage().heapUsed`--perhaps we could make sure node is running with 4GB of memory it can use?
Yes, the conversation suggests that setting the NODE_OPTIONS parameter with --max_old_space_size=4096 helped address the issue of ensuring that Node.js runs with 4GB of memory.
0 references
same address that the ETH was sent to?
Yes, the same address that the ETH was sent to can be used.
0 references
shall I change the PR status to be non draft?
Yes, change the PR status to be non-draft.
0 references
should have some time later today for a read-through--also, a few quick answers - --> * isDataURIEnabled: noticed it was removed in your branch, but we thought it could be nice to keep--I removed this as it was only put in place because we were unsure if OS would support dataURIs in time for the initial Nouns launch. Thinking keep it as a fallback in case dataURIs stop working or the Nouns on-chain data otherwise breaks?--> * NFTDescriptor: could it make sense to convert it into a contract? we find it generally more convenient to work with contracts, and not sure of the reasons it's a library atm--Thought other contracts may want to re-use and didn't really need any of the features of a full contract. Don't feel too strongly either way--> * Inflate: it's currently a private library; curious for your thoughts on whether it should become a public library or a contract?--Curious how much gas the passing of calldata between the contracts would add. if negligible, then I think that'd make sense.--> * ISVGRenderer.Part.palette is a pointer to an SSTORE contract: we were thinking to experiment with it being bytes similar to the image part, but thought maybe you explored that and had reasons to keep it as a pointer, like gas savings? the benefit of such a change is mostly a design consideration, i.e. making SVGRenderer unaware of storage sources, thus not imposing such a constraint on its users--Was mostly just playing around with SSTORE2. That seems like it could be a reasonable solution π
0 references
so I'll ping you once I am done merging master into the branch--re: the subgraph CI branch, seems like it's important to get it running of self hosted? curious why it's important to self host these runs?
The question was about why it's important to self-host the subgraph CI branch. The answer provided by solimander#7468 is that they were hitting the limit on GitHub Actions minutes per month for the free plan, so they decided to self-host. They also mentioned that they can take another look at the cost, as it is likely insignificant.
0 references
Sounds like the best of both worlds: the DAO can choose a buffer and continually re-supply it, but if a builder needs more funds sooner than we can swap, the mev/arb bots will work to swap the rest
0 references
test env would be helpful.--Clarifying qs:--1. Do you see it as there's a param somewhere in the code that's like `V2_DAO_START_BLOCK` (set when we deploy v2 I guess) and the UI uses v2 for anything after that block and v1 for anything before? Trying to nail down exactly what you mean by have it support both V1 and V2--2. Is the current state of DQ visualizer good to go or will changes need to be made?--Assuming DQ visualizer is good to go and 1 is the correct understanding ... my guesstimate is this would only take a few days. What sort of timeline are you all hoping to move on for this?
The question about supporting both V1 and V2 was answered by elad#6192, who suggested reading the DAO proxy's implementation address to see if it changed. The current state of the DQ visualizer was also addressed, with elad#6192 stating that it's generally good but they would want to run more tests once it's merged to master and the UI is deployed. The timeline for this task was discussed, with elad#6192 expressing a preference for the sooner the better.
0 references
thanks! --1. I think you can read the DAO proxy's implementation address and see if it changed https://etherscan.io/address/0x6f3e6272a167e8accb32072d08e0957f9c79223d#readContract#F2--2. I think it's generally good, we would probably want to run a few more tests once we're merged to master and have this UI deployed (I imagine us merging the v2 branch to master, then you refreshing your branch off of master)--wdyt?
0 references
thanks! just trying to understand why two different webapp deployments?--can we make it so the 2nd one that supports DQ looks cleaner with v1 props? (e.g. just not show to DQ modal?)
0 references
Thank you!--Can definitely remove retirement logic, it'll make the descriptor much simpler. --Curious if you can share more specifics on outstanding decisions regarding image retirement?
There are no specific decisions made regarding image retirement yet. The community has varying opinions on trait retirement mechanics, and they haven't reached a consensus on how traits should be selected for retirement. They prefer to leave it out of the implementation until they are in agreement.
0 references
Thank you for taking the time to articulate your thoughts, this is very helpful!--I think we agree that builder UX is important, and pegging payment to USD is already a huge improvement.--In practice the suggested solution can be such that most all props are paid directly in USD, as a function of how large the DAO decides the βUSD bufferβ should be (aka the DAOβs USD position).--In addition, even if builders find themselves receiving IOU tokens, their challenge is quite minimal since what they have received is USD-pegged and gets redeemed by clicking on the βredeemβ button.--Btw your feedback did get us thinking: perhaps we should let anyone call redeem for anyone else with IOU balance; this way anyone in the community can help them out by converting their IOUs into stablecoins.--re: having a βswap podβ, I think the DAO benefits from having these swaps execute trustlessly; it should lead to more predictable outcomes, without this task having to fight for anyoneβs attention (Nouner attention seems like a scarce resource we should not use lightly). In addition, a trustless solution lends itself more as a public good for other DAOs to use, and that seems Nounish.--I suspect a point where we might disagree most is on the cost of builders not getting paid immediately. --- I am confident we can configure this contract to serve us well, even if it means increasing the premium bots get to trade with us-- Even if there will be a delay, weβll likely still pay partially thanks to the USD buffer, and I believe in most cases a short delay wonβt pose a material problem for builders
0 references
thank you! quick replies:--* isDataURIEnabled: was thinking to keep it for the sake of forkers, for the case of perhaps wanting to launch before all the art is ready, with some easier-to-deploy URI-based placeholder. perhaps something like a reveal moment as well. does that make sense? --* Inflate: will look into gas implications and update--* palette: will look into changing it then from a pointer to bytes
0 references
that makes sense-in that case maybe it would also help to get the amount of tokens it *can* accept? i.e has enough ETH to pay for it
The question was answered in the conversation. In short, the function should output amounts you can go right ahead and buy/sell, knowing it won't fail due to insufficient ETH balance.
0 references
that's not too bad imo. if expiry is in 1 year we would have plenty of time to pass an extension, and even if we missed it, the expiry wouldn't have to be irreversible. perhaps at expiry we set the vetoer to the dao itself?
0 references
the idea behind a 2 step vetoer transfer is if the veto address is set accidentally it can be changed prior to being accepted?
Yes, the idea behind a 2-step vetoer transfer is to prevent accidental loss of the veto in the event of a typo or bad copy/paste. It is considered too critical not to have a two-step transfer process.
0 references
the pending/active proposal limit? it prevents spam as you can only create `nouns_held / (proposal_threshold + 1)` proposals at a time. if you use the transfer trick, and no longer meet the proposal threshold for any previously created proposal that's not in a final state, then it can be cancelled
0 references
these parameters are modifiable by proposal post deployment?
Yes, the parameters are modifiable by proposal post deployment. As davidbrai#5671 mentioned, the parameters are modifiable in future proposals.
0 references
the token doesn't change in prod, but not sure I understand how the token ABI is related?
0 references
^ Think I've fixed these issues. Testing right now by doing a mock upgrade. Will update ... --One thing I did notice though ... it seems to be counting no votes twice? Double checking that I'm not crazy but seems like (if true) that's probably due to this line (and line 169 as well) in the subgraph code ... -https://sourcegraph.com/github.com/nounsDAO/nouns-monorepo/-/blob/packages/nouns-subgraph/src/nouns-dao.ts?L155--thoughts from anyone on this?
Yes, you're right, it seems to be counting no votes twice due to the mentioned line in the subgraph code. Elad#6192 confirmed this and said they would push a fix to your branch.
0 references
to have confidence that we're backwards compatible, I think we want to see this version of the webapp working well when:--* interacting with v1 (before the upgrade)-* interacting with proposals created in v1 after the upgrade: make sure the UI isn't showing anything related to DQ-* interacting with proposals created in v2: expect to see DQ in the UI --wdyt?
0 references
too late to update total supply and creation block to share a slot? π
I'm in favor of trying to squeeze it into v2 π
0 references
Tough to tell at a quick glance, but do you know if theyβre using a similar Descriptor->Renderer arch as you guys implemented?
They are not using a similar Descriptor->Renderer architecture. Elad#6192 mentioned that the other project seems to have a more complex implementation due to higher variation in their image formats, such as statics vs animations, and standard vs non-standard formats.
0 references
true! or have abstain votes weigh less; how about a dynamic abstain threshold? π
0 references
Trying to get clearer on why this is safer --Seems like the assumption is that the vetoer account is compromised; if that's the case they can shoot down any proposal, so then the vetoer would never be changed as long as the attacker is online --If the attacker had enough keys to hijack the veto multisig they could probably kick other signers out and take full control and stall the DAO --So not sure this change would add security --Perhaps it's being suggested more as a cultural change, to give the DAO more of a say in the matter?
The question was about why the proposed change is safer and if it adds security. The conversation suggests that the change mostly protects from a scenario in which someone has temporary control of the vetoer account and uses it to change the vetoer to their own account. Examples of temporary access include access to a browser with MetaMask on or access to a hardware wallet. The change could also be seen as a cultural change, giving the DAO more decision power over who gets to veto decisions.
0 references
unless there's additional testing you think we should do, the next steps as we see them are:--1. merging the branch to master after fixing any outstanding minor comments on the PR. Do you want to review more before we do that?-2. submitting a proposal to update the descriptor--<@850478993463443487> wdyt?
Yes, the next steps as you see them are:--1. Merging the branch to master after fixing any outstanding minor comments on the PR. Solimander#7468 is doing a final quick pass and then it will be merged.-2. Submitting a proposal to update the descriptor. Solimander#7468 will get the proposal up and help with the description.--Solimander#7468 will also edit the description in the proposal hardhat task and let you know once it's good to go.
0 references
update on token buyer's price feed:--* it seems best to use the ETH/USD oracle rather than USDC/ETH, since ETH/USD heartbeat is 1 hour, whereas USDC/ETH is 24 hours-* there's the risk of USDC depegging from USD, but we don't think it's significant enough to complicate the price feed solution at this time -* we don't think it's necessary to introduce another oracle, given the validity checks we impose on chainlink: 1 hour refresh rate, hard bounds on price (e.g. revert if not between $100 and $100K)--it's worth noting that other big protocols are doing even less checks than that π -liquity is the most serious--a quick survey:--* compound v3 uses chainlink and only checks for a positive price (not staleness check)-* Aave v2 and v3 use chainlink and also only check for a positive price-* fei checks positive price AND round staleness `roundId == answeredInRound`-* yearn uses chainlink and has *no validity check*, it would only use another oracle if chainlink reverts-* liquity uses chainlink with a fallback to tellor, and has the most checks: positive price, timestamp staleness, max deviation from previous price (50%)--links:--* compound v3: https://github.com/compound-finance/comet/blob/ad6a4205a96be36417632afba2417f25b6d574ad/contracts/Comet.sol#L499-* aave v3: https://github.com/aave/aave-v3-core/blob/master/contracts/misc/AaveOracle.sol#L112-* fei: https://github.com/fei-protocol/fei-protocol-core/blob/develop/contracts/oracle/ChainlinkOracleWrapper.sol#L51-* yearn: https://github.com/yearn/yearn-lens/blob/master/contracts/Oracle/Calculations/Chainlink.sol#L55-* liquity: https://github.com/liquity/dev/blob/main/packages/contracts/contracts/PriceFeed.sol#L350---<@850478993463443487> wdyt?
0 references
upgrade prop is up https://deploy-preview-585--nouns-testnet.netlify.app/vote/20
0 references
What can I do to help?-Iβd love a test noun for the culture π -And happy to test things, just let me know.-benbodhi.eth
To help, you can follow the instructions in the pinned message and start bidding for a noun at https://deploy-preview-462--nouns-testnet.netlify.app/.
0 references
where are the developers going to talk dev?
0 references
would it be a terrible idea to require the dao to approve (presumably via proposal) any transfers of the veto?
0 references
yeah, but question remains for `delegateBySig`, which is in ERC721Checkpointable-wdyt?
0 references
yeah, for that reason would not make these changes in the branch we use to deploy. thoughts on, at a minimum, adding a note in the main branch, and possibly fixing in a separate branch?
A separate branch for forkers is a good minimum, and it's worth mentioning it in the project README.
0 references
yeah that makes sense ... two questions:--1. What do you think the best way to test the v1 => v2 bit is? Deploy v1 and v2 on testnet and do the switch there?-2. This might be a dumb question and I think I asked a version of it before ... but for a given prop how would you suggest I fetch the information that it should / should not be DQ enabled
1. The best way to test the v1 => v2 bit is to deploy v1 and v2 on testnet and do the switch there, as elad#6192 mentioned that they will work on deploying a V1 to goerli.--2. To fetch the information whether a given proposal should or should not be DQ enabled, you can read proposal data from gov `proposals(144)`. V2 is different from V1 in adding `totalSupply` and `creationBlock`. If these values exist and are greater than zero, this proposal was created in V2, as mentioned by elad#6192.
0 references
you prefer that over adding the art in the proposal?
Yes, solimander#7468 prefers adding the art in the proposal because the cost is somewhat negligible either way, and they can take advantage of the one digit weekend gas prices.
0 references
you think the way `estimateGas` is implemented is to blame?
The issue with `estimateGas` might be related to the implementation, and using a local Anvil node could provide better performance. The gas optimized version of inflate.sol resulted in a gas usage of 111,930,036, which is within the expected range. The team is considering implementing deflate read gas, as it seems low enough not to cause issues. They will check the implementation again on Rinkeby once it's integrated into the contracts and also test other marketplaces besides OpenSea.
0 references
