While activating the crucible strategy I reach this screen:

When copying the example parameters from here the add button becomes inactive.

Expected behavior

Committed code should conform to the expected formatting & linting rules.

Actual behavior

No enforcement of formatting / linting rules as part of the PR.
When lint is run locally there are a number of files that get auto-fixed.

Steps to reproduce the behavior

The lint target uses --fix, when run locally on a fresh checkout I'm getting many local changes.
npm run lint

git status                                                                                                             
On branch linting
Your branch is up to date with 'origin/linting'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   package-lock.json
	modified:   src/strategies/balance-in-vdfyn-vault/index.ts
	modified:   src/strategies/cyberkongz/index.ts
	modified:   src/strategies/holds-tokens/index.ts
	modified:   src/strategies/hopr-bridged-balance/index.ts
	modified:   src/strategies/index.ts
	modified:   src/strategies/loot-character-guilds/index.ts
	modified:   src/strategies/mcn-farm/index.ts
	modified:   src/strategies/mstable/index.ts
	modified:   src/strategies/occ-stake-of/index.ts
	modified:   src/utils.ts

Expected behavior

Actual behavior

Steps to reproduce the behavior

Create an alias for strategies where one strategy can have different names,

Example:

erc20-with-balance: withBalance
with-balance: withBalance

both erc20-with-balance and with-balance should use the with-balance strategy

Expected behavior

Testing the aavegotchi-agip-37-wap-ghst strategy using the pagination strategy with the address 0x26cf02F892B04aF4Cf350539CE2C77FCF79Ec172 should return a voting power greater than 0.

Actual behavior

Instead, it returns an error as you are casting your vote with a 500 error code in the console from the score API.

One thing I found strange, was the paginations strategy works fine using the playground, it only fails when calculating the voting power within a snapshot instance.

working playground link

Steps to reproduce the behavior

Test with any address after adding the pagination strategy into a snapshot instance while using the strategy params JSON as attached.

wapGHST json.txt

I have a query on how the snapshot uses blockTag in the option.
This issue is a continuation of the discussion below
#202 (comment)

@ChaituVR
We have custom staking contract and we decide the users' voting power by calling a get method in the contract.
How will snapshot.js will retrieve the past data based on the blocktag for this scenario?

Are you storing the data for the users anywhere in a DB?

reg:

ex: if I vote with 1 VP and in future, I may buy 100 VP and change the results)

if the user has already voted with 1VP, won't it be persisted in the DB and won't the user loses his ability to vote for the proposal thereafter?
Even if the user buys more tokens after voting, it should not impact the proposal because he has already cast his vote.

Use case

By this strategy, users can use different methods in their ERC721 contracts for calculating weights and provide different multipliers.

Example

PR: https://github.com/snapshot-labs/snapshot-strategies/pull/1000
Contract: https://goerli.etherscan.io/address/0xbb2e3b5cb7fd90e6b239d5a26a3508f8c779a79f#code

We can do this:

• Make it not possible to select "multichain" and "pagination" strategies from the UI

And later after we announce it we continue with these:

• Prevent someone to update strategies with a disabled one on the hub
• Make script to update space strategies to not use "multichain"

If space contains more than 5000 delegations it stop to read the next delegations. Subgraph says we can't pass more than 5000 into skip.

Should try to paginate with timestamp

Expected behavior

rewardToken is an "optional" field. Only the pool field is a required field as set in the schema.json.

Actual behavior

However, while testing the strategy out in the Playground - I see the following

Steps to reproduce the behavior

Test via the gysr-pending-rewards playground.
Sample params

• Network - Polygon Mainnet
• Symbol - UBT
• Pool - 0xaf8412fcfd3a9399f66e60894c1c8a20054d3d55
• Reward Token - 0x7fbc10850cae055b27039af31bd258430e714c62
• Address with non-zero score: 0x81218f94eb7ac182462158efb0666cb9d5e32783

Please let me know how I can set the "rewardToken" field to be optional. Perhaps my understanding of the schema setup is wrong. Would love to understand the problem here.

Update: This seems to be a display issue. I am able to execute the strategy without providing the rewardToken.

We should create a voting strategy that leverage solidity code to query voting power. We can do that without deploying any contract, see example of how to do that here: https://twitter.com/DestinerX/status/1446849311959093257

We should add "symbol" params for each strategies examples, for the one not having example we should add one.

This strategy queries ProofofHumanity.isRegistered(address) and returns true or false.

https://github.com/Proof-Of-Humanity/Proof-Of-Humanity/blob/master/contracts/ProofOfHumanity.sol#L1029

Would strategies that get the ERC20 token holder distribution on e.g. Polygon work too? I've looked into the code, but I couldn't find anything that was requesting other chains than mainnet, rinkeby or kovan. But I'd imagine that all that'd be needed is to input the right parameters to e.g. the erc20-balance-of strategy, right? E.g. setting network and provider correctly:

https://github.com/snapshot-labs/snapshot/blob/24b9f6ccaa41fa910b1a010dac07c862fbee5aab/src/locales/default.json#L590

Related to snapshot-labs/snapshot#3466

11

Logic: If the user has at least 1 voting power in any one strategy, return 1 else return 0

• Should be similar to https://github.com/snapshot-labs/snapshot-strategies/tree/master/src/strategies/ticket-validity
• Add a way to pass multiple strategies options.strategies , maximum of 3 (for example to pass erc20-balance-of and contract-call strategies)
• options.min - to check the minimum voting power in one strategy (Default to 0)

Status Quo

• there exist voting strategies for ERC1155 tokens, but none of them allows to apply a multiplier to the voting weight of a specific token
• something like this exists for ERC721 tokens (ERC721-with-multipliers)
• the same would be very cool for ERC1155 tokens, since it would allow one ERC1155 with multiple tokenId's to represent a whole electorate

Acceptance Criteria

• there is a new strategy ERC1155-with-multiplier
• it allows the location admin to apply a multiplier to the voting weight of a specific tokenId

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Right now it is hard to get delegations of space without a space name, especially in the playground, allowing it from strategy params will fix that and also child DAOs can access delegations of parent DAOs

Currently we show strategies in the UI using their id like "erc20-balance-of", it's not so friendly, we should have a name and a short description for these strategies like "Token balance", "Voting power is based on a token ERC20 balance."

Expected behavior

Spacey2025 is a block-chain tower defense game (https://spacey2025.com). The voting power rules are like below

• SPAY x1
• LAND x600
• Ticket x1500
• Tower x6

Actual behavior

Create a new strategy

Steps to reproduce the behavior

n/a

Case

A lot of people are showing the wrong amount of nfts they hold in the snapshot vote with an 1155 smart contract,

Proposal (with comment box): https://snapshot.org/#/xphunksdao.eth/proposal/0xc0bad5da5de8e248f380b59498ace9c3e16644d607a01778e00861ee715eee36

Expected behavior

The strategy's function: to calculate the VP of all token IDs under an erc1155 contract.

This ticket is supposed to identify if there's something wrong with its function.

Steps to reproduce the behavior

Tested with the user address 0x06658Fd70023f527BFAc1A6d9141C56d99c65129 who actually owns dozens of the contract NFT in wallet at the snapshot, while in the playground it shows 2.

Hi,

I'm interested in building a strategy to vote by staked tokens in bancor. I've taken a look around the internet, but I haven't found too much. I'm specifically interested in OCEAN/BNT. But I can make the strategy generic. Here's a bit of research:

• to my knowledge for Bancor V2 there's no working subgraph. All I found was https://github.com/blocklytics/bancor-subgraph-v2 but it's far from complete and not running online.
• It's non-trivial to go from OCEANBNT pool token to OCEAN staked. There are multiple moving parts
• The attempt here works with logs https://github.com/w1kke/snapshot.js/blob/master/src/strategies/ocean-bancor/liquidity-snapshot/index.js but I see a problem: In case the logs become too many, it may be that the Infura node times out. But I'm not sure. Ideas?
• snapshot doesn't have any pre-configured strategies for bancor LPs. I checked this repo.

Does anyone have tips or advice on how to get the number of staked tokens in a bancor pool?

Expected behavior

Each voter's balance for the specified token at address should be scaled by an index value read from the index function on the specified indexAddress contract.

This is desirable for Olympus-style protocols like OlympusDAO and KlimaDAO which have a "wrapped staked" token whose voting power is tied to an ever-increasing index value.

Expected behavior

I can create a remote branch from my command line and create a PR from it.

Actual behavior

Trying to push to a remote branch gives me the error:

remote: Permission to snapshot-labs/snapshot-strategies.git denied to ori-wagmi.
fatal: unable to access 'https://github.com/snapshot-labs/snapshot-strategies.git/': The requested URL returned error: 403

Steps to reproduce the behavior

1. clone the snapshot-strategies repo locally
2. create a new branch ori/addApiReadme
3. Make changes, commit
4. git push --set-upstream origin ori/addApiReadme

I verified my git config looks correct:

c:\code\snapshot-strategies>git config --global -l
[email protected]
user.name=ori-wagmi
credential.helper=manager-core

I've tried authenticating both via the browser, and with a PAT. Same error both times.

c:\code\snapshot-strategies>git branch
  master
* ori/addApiReadme

c:\code\snapshot-strategies>git push --set-upstream origin ori/addApiReadme
info: please complete authentication in your browser...
remote: Permission to snapshot-labs/snapshot-strategies.git denied to ori-wagmi.
fatal: unable to access 'https://github.com/snapshot-labs/snapshot-strategies.git/': The requested URL returned error: 403

Is this an issue with my local machine setup or the snapshot-strategies repo settings? Any idea how to resolve?

The strategy code should be on the Score API cuz we still need pagination there, but we should remove it as a strategy.

• Make it impossible to select this strategy in space settings on UI and hub
  as mentioned here #688
• Once we do the announcement about this, we can remove this strategy

Here is a good explanation of what Radicle is building: https://radicle.community/t/feedback-on-nft-community-tokens/2455

What you need to do:

• Join Radicle Discord https://discord.gg/TmsafqP8kb
• Looks community-tokens channel here: https://discord.com/channels/841318878125490186/875668327614255164/897514173066530846
• Create a strategy that take voting power from the Radicle funding subgraph with the entity NFT and field amtPerSec. Each voter can have multiple NFT, the voters voting power should be the sum of all the amtPerSec.

Hi there, I'm curious about a strategy that uses NFTs from ArtBlocks, which is on a shared contract but with a token ID range between two numbers. So for example, anybody that holds a Meridian token can vote through that, but if somebody only has other ArtBlocks tokens from the same contract address, they should not be entitled to vote. Happy to open a PR but might need a bit of a guidance in terms of the best approach for this.

This is a contract ERC1155 that include all the Orca pods https://etherscan.io/token/0x0762aa185b6ed2dca77945ebe92de705e0c37ae3#inventory each pod have their own tokenId. Each token can have multiple holders. We should create a strategy "orca-pod" to give 1 voting power for each holder of a specific tokenId holder. Ideally the weight should be a param, to allow changing vp from 1 to any amount

Hello,

What should i fill the "network", "addresses", and "snapshot" slot in example.json for creating new strategy?

sincerely,
yosep.

Expected behavior

As on block 192690 of 1666700000 (Harmony test net), the address 0x29c2eC57803f8b695f02613E5FA1749c165c5057 has a voting power of 1e22 wei per the harmony-staking strategy.

$ curl -H "Content-Type: application/json" -d \
'{"method":"hmy_getValidatorsStakeByBlockNumber", "params":[192690],"id":1}' \
https://api.s0.b.hmny.io | jq .result
{
  "0x29c2eC57803f8b695f02613E5FA1749c165c5057": 1e+22
}

Actual behavior

The reported voting power on this harmony-testnet.eth proposal is zero.

Looking at the logs, the vote power is fetched from https://score.snapshot.org with a POST request. The request made for the harmony-testnet.eth space appears to be using the mainnet chain ID under the strategies field. Below is a copy of the request payload; the mismatch is tagged with a pound sign.

{
  "jsonrpc": "2.0",
  "method": "get_vp",
  "params": {
    "address": "0x29c2eC57803f8b695f02613E5FA1749c165c5057",
    "network": "1666700000",
    "strategies": [
      {
        "name": "harmony-staking",
        "network": "1666600000", # mismatch
        "params": {
          "symbol": "ONE"
        }
      }
    ],
    "snapshot": 192690,
    "space": "harmony-testnet.eth",
    "delegation": false
  },
  "id": null
}

Steps to reproduce the behavior

• Add the private key for 0x29c2eC57803f8b695f02613E5FA1749c165c5057 to your wallet.
• Connect MetaMask on the proposal link.
• Choose an option and click on vote.

Case

As quoted as a representative strategy in the official doc, "erc20-with-balance" strategy allows the space owner to check the min amount of token required to vote.

During the test, if I add the parameter “minBalance” and set the value to "10" where the wallet has only 5 token at snapshot, it still gives 1 voting power.

Expected behavior

Any NFT holder can vote on proposals when using the "ERC-1155 Balance Of" strategy, regardless of when it was purchased

Actual behavior

Only NFT holders who bought the NFT before the proposal was created can vote on the proposal

Steps to reproduce the behavior

You cannot vote on the proposal if this is the order of steps taken

1. Use the "ERC-1155 Balance Of" strategy as a voting requirement
2. Create proposal
3. Buy NFT
4. Unsuccessfully try to vote on the proposal

Alternatively, you can vote on the proposal if this is the order of steps taken

1. Use the "ERC-1155 Balance Of" strategy as a voting requirement
2. Buy NFT
3. Create proposal
4. Successfully try to vote on the proposal

Hi, apologies if this is the wrong repo for a feature like this. I'd like to create a proposal with 1,000 different options (simply using integer IDs, #0 to #999), allowing users to vote on their top 5 or top 10 of those options. Then using some sort of rank voting to determine which options among all of them tend to be most preferred. Happy to help develop this feature with PRs but wonder if something like this is even possible within Snapshot, or with a custom plugin of some kind.

Related to snapshot-labs/snapshot#3466

This strategy is similar to ERC-20 Votes, except that it also allows individual delegators to override their vote on a particular proposal if they wish. This is most useful for social (off-chain only) proposals.

If an account has any delegated voting power returned from getVotes, adds that value, minus the balances from any delegators that have also individually voted.

If an account is delegating to itself, then its own token balance will already be included in the getVotes return value.

If an account is delegating to a different valid address, adds the local token balance. The account must be delegated to another valid address, otherwise the local token balance will not be added.

Primarily for token contracts using OpenZeppelin's ERC20Votes: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Votes.sol

However the getVotes method can also be overridden in the options too if need be.

Example : https://github.com/snapshot-labs/snapshot-strategies/blob/master/src/strategies/moloch-all/index.ts#L7-L84