Conversation
…sive (#78) * docs(guard): clarify delegation is additive, not Governor-style exclusive The delegation explainer said "delegateVoteTo does not reduce your own votes". That is technically correct — dEURO Equity uses additive, non-exclusive delegation: delegateVoteTo only writes delegates[msg.sender], and votes() = balanceOf x holding-duration is independent of delegates[] (Equity.sol:192-193, 259-262). The delegator keeps their full votes; the delegate can additionally count them. But the phrasing collides with the common ERC20Votes/Governor mental model, where delegation is EXCLUSIVE (your weight moves to the delegatee and you keep none). Readers expecting that reasonably read the sentence as wrong. Clarified: non-custodial AND additive, contrasted explicitly with Governor-style delegation. Frontend copy only, no behavior change. * docs(guard): fix misleading "on top of its own" — signer holds no nDEPS On-chain the guard signer holds 0 nDEPS (votes=0, balanceOf=0), so "count your votes on top of its own" wrongly implied the guard has votes of its own. The additive/non-exclusive core is correct (verified against the deployed Equity 0xc71104... via Sourcify + on-chain), but the signer's entire veto power comes from delegators. Reworded accordingly.
#82) * fix(rpc): stop multicall cache from replaying transient errors forever ethers-multicall-provider's internal DataLoader (cache enabled by default) caches per-call Error results and only clears entries when a load fulfills. A single transient RPC failure (e.g. one HTTP 500) on a multicall batch is therefore replayed from the cache for every future identical call (same to+data+blockTag): retries and later monitoring cycles never reach the RPC again and the service stays down until a process restart. Wrap with cache=false: per-tick call batching is unaffected, and since latest-block entries were cleared after every successful load anyway, no effective caching is lost. withRetry becomes able to actually recover from a transient multicall failure. * test(rpc): finish provider network bootstrap before arming the failing batch Otherwise the intentionally failed first batch also takes down the lazy eth_chainId network detection, which logs noise and leaves a 1s retry timer that can trigger jest's force-exit warning.
Danswar
approved these changes
Jul 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automatic Release PR
This PR was automatically created after changes were pushed to develop.
Commits: 1 new commit(s)
Checklist