# Custom Sybil Resistance Political, social, and economic systems often need Sybil resistance. Sybil resistance is anything of the form: *1 person => 1 x* e.g., * [ ] 1 person => 1 vote (democracy) * [ ] 1 person => 1 stimulus check * [ ] 1 person => social security check * [ ] 1 person => 1 number of tokens (fair airdrop) * [ ] 1 person => 1 player (play-to-earn game preventing spam) * [ ] 1 person => 1 number of comments (social network preventing spam) * [ ] 1 person => 1 account (generic application preventing spam) * [ ] 1 person => 1 number of accounts (generic application preventing spam but a little more lenient) ## Standard Sybil Resistance To just see whether a unique person owns a wallet address, you may visit [Integrating Human ID](/for-developers/start-here.md) ## More Advanced Sybil Resistance Sometimes you want to prove Sybil resistance for a specific action. E.g., if a user wants to vote in multiple elections from different addresses as to not reveal their voting history. This can be done by giving each election a unique `actionID`. Importantly, this also means bribery would be easier. Imagine an action somebody doesn't care about. That person can provide a new address that `actionID`. One can imagine a DAO vote where a bad actor is passionate about the outcome, and can create 1000 new address, then bribe 1000 random people to register one of those addresses for that specific `actionID`. Since the random people don't care about the vote outcome, they don't mind giving away their uniqueness to the new address for that particular `actionID`. For the default `actionID`, it's far harder to launch a large-scale bribery attack, as giving up a vote to a briber is giving up everything to a briber: all future votes, universal basic income, and airdrops will go to the briber. While some people would gladly give up these rewards for the right price, doing so would require the presentation of government ID in order to participate in a black market. This risk far outweighs any rewards, so we assume such bribery on the default `actionID` will be negligible. ## How to set an actionID To prove uniqueness with respect to a specific action, you must create an actionId. Please use a large random number less than `21888242871839275222246405745257275088548364400416034343698204186575808495617` (the bn254 scalar field order). Let's say your actionId is `11223344556677`, and after your users are done proving uniqueness, you want to them to be sent back to yourwebsite.com/yourcallback. Then, they may visit [https://holonym.io/prove/uniqueness/11223344556677/yourwebsite%2E](https://holonym.io/prove/uniqueness/1234567890/yourwebsite.com)[com%2Fyourcallback](https://holonym.io/prove/uniqueness/1234567890/yourwebsite.com) You can then view their verification status with respect to the custom actionID by the standard steps in [Integrating Human ID](/for-developers/start-here.md). Simply replace the `actionID` in the code examples with your custom `actionID`. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.holonym.id/for-developers/custom-sybil-resistance.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.