Bulk donation support #96

mds1 · 2021-08-11T14:33:57Z

Closes #76

The GrantRoundManager contract, and in particular the donate method, feel a bit clunky now, but I'm not totally sure how to clean it up. There's a few things that we could handle in separate issues to make it cleaner, so curious to hear thoughts around this:

Making the payee address the grant ID (Discuss: Use a grant's `payee` address as it's ID #54) removes a validation check
Add an assertValidContribution(address token) method to the GrantRound can be used to combine the isActive and donationToken checks into a single call
Making the GrantRoundManager inherit from SwapRouter (Update `GrantRoundManager` to inherit from Uniswap's `SwapRouter`, instead of call an external router #74) would remove approvals and transfers that are currently needed
Other ideas?

Current code coverage results are below

- add test that ensures only dust remains after swap - add test to verify donation input ratios - add test for duplicate swap tokens

contracts/.solhint.json

corydickson · 2021-08-11T15:48:51Z

contracts/contracts/GrantRoundManager.sol

+  IERC20 public constant WETH = IERC20(0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2);
+
+  /// @notice Scale factor
+  uint256 internal constant WAD = 1e18;


decimals here may lead to misleading amounts for tokens like USDC which only go to 1e6

Hm, how so? Even if USDC amount where 1e6 =1 USDC, say you want 25% of 1 USDC, then you'd have 1e6 * 0.25e18 / 1e18 = 250000 = 0.25 USDC

right but what if someone tries to swap 0.2500009 USDC and submits that to the swap method on uni won't it revert?

Do you have an example of how we might get such a value? When we divide by 1e18 at the end, we'll either be left 250,000 (0.25 USDC) or 250,001 (0.250001 USDC) because there's only 6 decimals of precision when do you tokenDecimalsUsdc * xe18 / 1e18

corydickson · 2021-08-11T15:50:02Z

contracts/contracts/GrantRoundManager.sol

+  struct Donation {
+    uint96 grantId; // grant ID to which donation is being made
+    IERC20 token; // address of the token to donate
+    uint256 ratio; // ratio of `token` to donate, specified as numerator where WAD = 1e18 = 100%


for swaps with different decimals we could floor the amount for the tokens with the least amount of significant figures

Seems related to the above comment, but I'm not sure what you mean here and where you need to floor things that isn't already floored by integer division in Solidity?

maybe I'm missing something, but it's not related to the calculation per say but when we transfer an amount, emitting one value but really another has been sent to the contract (even if it doesnt revert)

The _donationAmount that is transferred is the same value as we emit in the GrantDonation method. Sorry, I don't think I understand the issue you are pointing out 😬

@corydickson I'm just running the example in my head and i don't see an issue either.
When donate is invoked for a given token -> sum of ratios should be 1e18.

So if we have a token with 16 decimals and contributions are made to 3 diff grants -> 5 , 5, 10
The ratio would be 25%, 25%, 50%.
The frontend would backfill the last 2 decimals with 0 and send it.

So once we do the swap to 18 decimal token -> you'd still have the same ratio of 25%, 25%, 50% right ?

The only scenario where this might mess things up is if we had a token > 18 decimals (which is not something we need to be bothered about)

contracts/test/GrantRoundManager.test.ts

contracts/contracts/GrantRoundManager.sol

apbendi

There's a good amount of complexity in what we're doing here, so really nice job tackling this 👍

I left some comments and questions and will follow up further based on responses. Thanks!

contracts/contracts/GrantRoundManager.sol

apbendi · 2021-08-11T16:32:16Z

contracts/contracts/GrantRoundManager.sol

+
+    // Token approvals of common tokens
+    // TODO inherit from SwapRouter to remove the need for this approvals and extra safeTransferFrom before swap
+    IERC20(0x6B175474E89094C44Da98b954EedeAC495271d0F).safeApprove(address(_router), type(uint256).max); // DAI


Just want to make sure I understand: as currently written, the donate method will fail if it's not using one of these pre-approved tokens, and there is no mechanism for the contract to approve new ones. Correct?

Inheriting from SwapRouter means we'd become a custom v3 router, and users would have to trust (or verify by inspected verified source code) that we did not modify the router functionality in some malicious or unsafe way. Correct?

Correct on all counts! If for whatever reason we don't end up inheriting from SwapRouter, I think we'd want a public method where you pass in a token address and it approves the SwapRouter to spend MaxUint of that token. Otherwise we have to check allowances every donation which would get very costly

Got it, sounds good. I think we want to go this route (ha!). Created this issue to track as a separate PR: #99

Just a clarification -> Even if we inherited the list -> wouldn't we still have to do an approve for every token on the list right ? (the only diff is we won't be hardcoding every token within this contract )

So here is the flow when you normally use Uniswap as a user:

Approve router to spend your tokens

Call swap on router, which takes your tokens and executes swap

(1 total approval, 1 transferFrom)

Here is our current flow:

Approve manager to spend your tokens

Manager approves router to spend it's tokens

Call donate on manager, which takes your tokens, the router takes tokens from manager to execute swap (no more approvals)

(2 total approvals, 2 transferFroms)

So once we inherit from SwapRouter, we'll migrate to the top flow, which will reduce approvals and transfers

contracts/contracts/GrantRoundManager.sol

apbendi · 2021-08-11T16:43:39Z

contracts/contracts/GrantRoundManager.sol

+    SwapSummary[] calldata _swaps,
+    uint256 _deadline,
+    Donation[] calldata _donations
+  ) external payable {
    // --- Validation ---


The three steps executed in this method are:

Validate

Swap

Donate

These feel like good candidates for 3 distinct internal helper methods. It would add some gas overhead, but what we're doing is already super gassy, so it might be worth it from a code hygiene and comprehensibility standpoint.

Split up in 4fef97a

Hate to nitpick but I'm going to anyway: not a fan of the naming here. What would you think of something more like:

_validateDonations
_executeDonationSwaps
_transferDonations

Then once we have nice verbose names, we don't even need the comments :)

Also, missed this in my initial comments, but we could also extract the last for loop into _clearDonationMappings or the like. Actually, I wonder if you could make this a modifier? Something like:

modifier clearsTemp(SwapSummary[] calldata _swaps) { _; for (uint256 i = 0; i < _swaps.length; i++) { IERC20 _tokenIn = IERC20(_swaps[i].path.toAddress(0)); swapOutputs[_tokenIn] = 0; donationRatios[_tokenIn] = 0; } }

For context on the function naming, I used the same convention as the app of naming things <parent-purpose> to make it easier to understand something's purpose / where it fits in. So here the parent method is donate and we have 3 sub-methods of validation, swaps, and execution. I don't feel strongly about the naming, so I have no objections to renaming them if that reasoning doesn't convince you

Re: modifier, I'd personally vote against that since it's only used one time, so I'm not sure pulling it out adds any value, and just costs extra gas

Though I do think we should add underscores to prefix internal methods regardless, so good call there, but I'll hold off pending a final decision on naming

Wasn't aware we had that convention on the frontend. Does that come from Vue?

Yea it's based off their style guide: https://vuejs.org/v2/style-guide/#Tightly-coupled-component-names-strongly-recommended

A bit tangential, but @thelostone-mc perhaps worth mentioning that style guide in the CONTRIBUTING doc?

Got it. I can see how that convention makes sense for Components, but not sure it fits well for helper methods. The point of breaking the original function up was for code clarity, so easily grokable names seems pretty important. That said, don't feel strongly enough to block the PR or anything! I think I've made my case and will let you exercise your judgement!

Fair enough! Updated in 6ea6b59

- fix GTC name and symbol in tokens declaration - remove requirement to contribute for a round - split up core donate method into internal methods for readability - clean up lint warnings

thelostone-mc · 2021-08-12T07:44:36Z

contracts/contracts/GrantRoundManager.sol

+   * @param _donations Array of donations that will be executed
+   */
+  function _validateDonations(Donation[] calldata _donations) internal {
+    // TODO consider moving this to the section where we already loop through donations in case that saves a lot of


are we saying

keep the function

let the argument be Donation _donation

it gets invoked as the first thing in _transferDonations

It does seem a smart way to save gas but this would mean -> we'd do it after the swap happens which is I am not very comfortable about (but the argument could be made -> if you invoke it wrong -> it's not the contract's fault )

Yea pretty much! The benefits of the current approach are that you save gas in the event of a failure (by reverting before the swap), but downside is more gas overall since you repeat a loop. I don't think the extra gas is significant, so I think we should we leave this as-is for readability, and come back to it later when we focus on optimizing gas usage

mds1 added 6 commits August 11, 2021 07:12

feat: add support for batch donations to GrantRoundManager

bf77409

fix: donate and swap tests now pass with GrantRoundManager update

8b70596

chore: update solhint config so CI passes

a891025

chore: add MockToken SPDX license identifer and clarify input name

485cf89

test: add GrantRoundManager batch swap donation tests

d5ef4a2

test: add missing GrantRoundManager tests

a1354ac

- add test that ensures only dust remains after swap - add test to verify donation input ratios - add test for duplicate swap tokens

mds1 requested review from apbendi, thelostone-mc and corydickson August 11, 2021 14:33

thelostone-mc reviewed Aug 11, 2021

View reviewed changes

contracts/.solhint.json Show resolved Hide resolved

corydickson reviewed Aug 11, 2021

View reviewed changes

contracts/test/GrantRoundManager.test.ts Show resolved Hide resolved

corydickson reviewed Aug 11, 2021

View reviewed changes

contracts/contracts/GrantRoundManager.sol Outdated Show resolved Hide resolved

corydickson reviewed Aug 11, 2021

View reviewed changes

contracts/contracts/GrantRoundManager.sol Show resolved Hide resolved

apbendi reviewed Aug 11, 2021

View reviewed changes

various cleanup and improvements

4fef97a

- fix GTC name and symbol in tokens declaration - remove requirement to contribute for a round - split up core donate method into internal methods for readability - clean up lint warnings

apbendi mentioned this pull request Aug 11, 2021

Enable WETH & ETH Donations In Same Checkout #98

Open

apbendi approved these changes Aug 11, 2021

View reviewed changes

chore: rename donation functions

6ea6b59

mds1 force-pushed the bulk-donation-support branch from 886977a to 6ea6b59 Compare August 11, 2021 21:01

thelostone-mc reviewed Aug 12, 2021

View reviewed changes

thelostone-mc approved these changes Aug 12, 2021

View reviewed changes

mds1 merged commit 739effe into main Aug 12, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bulk donation support #96

Bulk donation support #96

mds1 commented Aug 11, 2021

corydickson Aug 11, 2021

mds1 Aug 11, 2021

corydickson Aug 11, 2021

mds1 Aug 11, 2021

corydickson Aug 11, 2021

mds1 Aug 11, 2021

corydickson Aug 11, 2021 •

edited

Loading

mds1 Aug 11, 2021

thelostone-mc Aug 12, 2021

apbendi left a comment

apbendi Aug 11, 2021

mds1 Aug 11, 2021

apbendi Aug 11, 2021

thelostone-mc Aug 12, 2021

mds1 Aug 12, 2021

apbendi Aug 11, 2021

mds1 Aug 11, 2021

apbendi Aug 11, 2021

mds1 Aug 11, 2021

mds1 Aug 11, 2021 •

edited

Loading

apbendi Aug 11, 2021

mds1 Aug 11, 2021

mds1 Aug 11, 2021

apbendi Aug 11, 2021

mds1 Aug 11, 2021 •

edited

Loading

thelostone-mc Aug 12, 2021

mds1 Aug 12, 2021

Bulk donation support #96

Bulk donation support #96

Conversation

mds1 commented Aug 11, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

corydickson Aug 11, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

apbendi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mds1 Aug 11, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mds1 Aug 11, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

corydickson Aug 11, 2021 •

edited

Loading

mds1 Aug 11, 2021 •

edited

Loading

mds1 Aug 11, 2021 •

edited

Loading