Airdrop Sybil Reviews: 7 Checks Before You Exclude a Wallet

Improve the decision record before applying the label

An airdrop review can go wrong before any model is evaluated: the wrong account is queried, a stale score is reused, a missing response becomes zero, or a recommended threshold is treated as the program’s actual rule.

DN’s thesis is that a useful exclusion review starts by preserving those distinctions. This article uses Human Passport documentation as a concrete scoring example and provides a local worksheet for the evidence handoff. It does not offer attack tactics, identify a real Sybil ring or claim that a checklist can prove a person’s intent.

1. Start with the program rule and the intended subject

Before reviewing a wallet, identify the program decision being made. Is the question whether an account meets a published participation criterion, whether a score response belongs to the intended account, or whether a suspected pattern needs investigation? Those questions require different evidence.

Record the policy version, relevant snapshot or cutoff, subject mapping and reason for review. A label such as “Sybil” is too broad to explain which rule was applied or what the record actually established. A useful reason instead names the condition and the supporting evidence.

Keep the subject mapping explicit. The worksheet uses a private alias, not a live wallet address or personal identity. The alias should link to the intended account and policy context in your own records. It does not establish who controls that account or how many other accounts they control.

The article’s review process is a proposed operating discipline, not a claim that every program owes the same appeal procedure or uses the same eligibility criteria. The applicable rules, contracts and legal obligations need their own review.

For a user considering participation, qualification is also separate from reward economics. DN’s points and rewards ROI reality check addresses costs and uncertain outcomes. This article addresses the evidence behind a score-related review, without instructing anyone how to farm or evade it.

2. Identify the scoring product before interpreting its number

A number needs a model, product and version. Scores from different systems are not interchangeable merely because the interfaces use the word “humanity” or display a similar badge.

Human Passport’s Models API provides model-specific results, including an aggregate option. Its documentation describes numeric scores from 0 to 100 and a distinct insufficient-data value. The Stamps system instead uses credential weights and a threshold mechanism. These are different evidence paths. [1] [2]

The tool requires you to choose Models or Stamps before it interprets a number. It also asks for a model or scorer-version reference. “Other” retains the record without inventing a conversion or borrowing a threshold from Human Passport.

A score of 83 is not presented here as an independently verified 83% probability that the subject is human. The source describes a score and its direction; this article has no basis for claiming per-wallet probability calibration. Keep that limitation in the report rather than translating the number into stronger language.

Similarly, do not import a recommended threshold from another product or campaign. The worksheet supplies none. Your program’s actual rule, configured scorer and relevant version are the evidence needed for the comparison, and the comparison still does not establish identity.

3. Keep insufficient data and request errors out of the failure bucket

One of the easiest ways to produce an unfair or simply incorrect review is to collapse every non-passing response into the same state. A low score, missing response and failed request do not mean the same thing.

The Human Passport Models API documents -1 as insufficient data to generate a score. It separately describes the 0–100 numeric range. The insufficient-data marker is therefore not a score below zero that should be fed mechanically into a threshold comparison. [1]

In the first invented case, the entered Models result is −1. The tool preserves “insufficient data” and produces no numeric pass/fail comparison. It does not replace the marker with zero, infer that the subject is dishonest or invent evidence from a sparse history.

A request error is kept separate too. The worksheet makes retained score text inactive when the declared result is a request error, so a value left in the form cannot silently stand in for a failed response. It also flags a conflict when “insufficient data” is declared alongside an ordinary numeric score.

Zero is different again. When a supported product returns a valid numeric zero, the tool retains it as zero and can compare it with an entered rule. That comparison remains a statement about the record, not permission to call a person fraudulent or to skip the program’s review process.

4. Write the threshold operator and its trade-off explicitly

Threshold equality is a decision, not a formatting detail. “Greater than 24.5” and “at least 24.5” produce different results for a score of exactly 24.5. A program should not leave that boundary to an analyst’s interpretation.

Human Passport’s threshold guidance describes the trade-off between screening suspected Sybils and excluding honest users. Its model tables also caution that the reported qualification percentages do not necessarily translate to each partner’s participation. A vendor benchmark is not a measured result for your distribution. [2] [3]

The second invented case uses a Stamp score of 24.5 and an entered threshold of 24.5. Select “at least” and the numeric rule is met. Select “greater than” and it is not. No other fact changes. Both results leave overall eligibility and exclusion authority unassessed.

Keep the threshold, operator and policy reference together. If the governing material says only “50+” or uses inconsistent boundary wording, resolve the implementation’s actual behavior before applying it to a contested case. The worksheet will not choose the operator for you.

Do not adjust the rule after seeing one inconvenient result without recording that change and its scope. A revised policy may be reasonable, but it is a different policy. Preserve the earlier evidence so reviewers can distinguish a corrected mistake from a newly introduced criterion.

5. Check the source, snapshot and relevant time window

A score can be genuine yet unsuitable for the decision being reviewed. It may belong to another account, scorer, policy version or observation window. Freshness and authenticity are different questions, and both need evidence.

The Stamps API data dictionary exposes a score timestamp and an expiration timestamp associated with the next Stamp expiry. The Embed component documentation also warns that frontend values should not be trusted to protect sensitive programs and directs integrators to verify through the backend API. [4] [5]

This local tool performs neither backend verification nor date arithmetic. It records whether you declare the evidence within the relevant window, outside it or unresolved. A numeric comparison can remain visible outside the window, but it is labelled as a literal comparison rather than current eligibility evidence.

For a real review, retain the response source, subject, scorer or model, observation time and the program’s time rule. A screenshot can help explain a disagreement, but the review packet should say exactly what the screenshot does and does not establish.

Do not refresh an old observation by exporting it again. The download has a new creation timestamp while retaining the source review date and your evidence references. If new source data change the conclusion, preserve the previous record and identify the evidence responsible for the change.

6. Separate the score rule from the rest of eligibility

A threshold test is one criterion. Treating it as the entire program decision can produce errors in both directions: approving an ineligible account or excluding an account for a reason the score never established.

Human Passport’s support guidance says websites choose their own thresholds and may apply requirements beyond the Passport result. It also explains that linked wallets can be counted as one participant in the Embed flow. A passing result is therefore not a universal access guarantee, and wallet count alone is not the product’s complete participant model. [6]

The tool keeps other requirements as a separate reader declaration: reported met, reported not met or unknown. It does not infer what the requirement is, verify it or use it to calculate a fraud probability. The reason-reference field should point to the actual condition and evidence in your private record.

In the third invented case, a numeric Models rule is met, but the evidence is declared outside the relevant time window and another eligibility condition is reported unmet. The tool preserves all three components. It does not overwrite them with one green “verified” badge or one red “Sybil” label.

When a dispute involves multiple wallets or linked identities, review the program’s own participant definition and the applicable source behavior. Do not broaden a score response into an unsupported claim about a person’s identity, motives or entire transaction history.

7. Record the reason and the review path before acting

A defensible review should explain what the evidence supports, what remains uncertain and who owns the next decision. It should not require a reader to reverse-engineer an exclusion from a score screenshot.

Keep the proposed reason distinct from the authority to act. A score rule being unmet is a numerical finding. A program decision may involve other criteria, a review procedure and an authorized operator. The worksheet does not perform that decision or mark any wallet for exclusion.

Use a local review reference to connect the record to the appropriate process. “Review completed” without a reference remains an explicit gap. Even a completion reference is reader-reported; the tool does not verify what was reviewed, whether the process was adequate or whether an action is authorized.

Design the handoff so another reviewer can inspect the policy, subject mapping, source response, model version, exact rule, time window and reason. Keep private personal information and secrets out of the public worksheet and its shareable export. Include only the minimum local aliases needed to locate the controlled records.

DN’s thesis is that exclusion reviews need better distinctions before they need more confident labels. An insufficient-data result can stay insufficient. A boundary comparison can stay a boundary comparison. A disputed context can stay unresolved. Preserving those limits gives the responsible operator a clearer decision packet without manufacturing proof of fraud.

Invented cases and bounded conclusions

These cases illustrate interpretation boundaries. They do not describe real wallets, current airdrop eligibility or measured detection accuracy.

Try changing the first example to a request-error status. The retained score becomes inactive; it is not reused as a valid response. Change an insufficient-data declaration to an ordinary numeric score without correcting the status and the tool reports a conflict.

The third case is a useful reporting test. A complete-looking numeric comparison must not hide an out-of-window observation or an unmet separate criterion. Conversely, those gaps should not be rewritten as evidence that the numerical subtraction or comparison was different.

Methodology and limits

The model interprets only two selected score products: Human Passport Models and Stamps. Models accepts an entered number from 0 through 100, or the exact −1 insufficient-data marker. Stamps does not inherit that marker or the 100-point range. Other sources are retained without numeric interpretation.

A declared request error makes retained score text inactive. An insufficient-data declaration paired with an ordinary number produces a conflict. Blank score text is unknown. A supported numeric zero remains known. This preserves information that would be lost if every unresolved response were converted into a failed threshold.

The reader supplies both the threshold and the operator: score ≥ threshold or score > threshold. Plain decimal inputs use up to 6 whole-number and 6 fractional digits, with exact scaled-integer comparison. These are worksheet representation limits. A threshold above 100 is retained for Models but warns that no in-range score can satisfy either supported rule. No threshold is chosen or recommended by DN.

Literal comparison is independent from application scope. A context match requires the policy, subject, source and model/scorer-version references plus an explicit declaration. The time-window field is also reader-declared; no timestamp or expiry calculation occurs. Missing, mismatched or out-of-window context does not erase the literal comparison, but prevents it from being presented as a verified current-scope result.

Other eligibility requirements and review completion are separate components. A reported completed review without a reference remains a gap; a reference does not authenticate completion or authorize action. The exported eligibility, identity and Sybil-classification fields remain “not assessed,” while exclusion authorization and execution remain false.

Every edit invalidates the previous result and download. Download rechecks raw inputs; clear resets entries and example provenance. The JSON preserves unused values, exact comparisons, declared context, gaps, errors and the invented-example label. The schema checks structure, not truth, fairness, legal compliance or entitlement. A download timestamp does not refresh the original evidence.

Frequently asked questions

Primary sources

The source list establishes the stated documentation scope. It does not authenticate reader-entered records or certify a deployed system.

1. Human Passport: Models API reference — Product-specific model results, the 0–100 range and -1 insufficient-data sentinel. No address was queried.
2. Human Passport: Scoring thresholds — Stamp-weight scoring and the trade-off between screening suspected Sybils and excluding honest users. No default is adopted by the worksheet.
3. Human Passport: Available models and recommended scores — Model/version distinctions and the warning that benchmark participation percentages need not transfer to each partner. No performance rate is reproduced.
4. Human Passport: Stamps API v2 data dictionary — Score, threshold, observation and expiry fields. Stamp expiration semantics are not generalized to every Models response.
5. Human Passport Embed: component reference — Sensitive program protection should verify server-side rather than trusting frontend score values. This worksheet performs no verification.
6. Human Passport Support: scores, access and wallet linking — Site-specific thresholds, additional eligibility and linked-wallet participant treatment. Updated 24 September 2026.

Related DN research

• Points and airdrop economics: the ROI reality check
• The limits of AI agent reputation evidence
• Know Your Agent: identity, trust and authorization
• Reconstructing an agent’s decision evidence