DAO Voting Eligibility with Wallet Auth: Server-Side Token Verification

DAO governance depends on one question: does this wallet hold enough tokens to participate? Most implementations verify this client-side, which is trivially spoofable. InsumerAPI verifies governance token holdings server-side across 33 chains, returns ECDSA-signed booleans, and never exposes the actual token count. Here is how to add server-side voting eligibility to your DAO.

The problem with client-side token checks

Client-side reads from an RPC endpoint are spoofable. Anyone can intercept the response, modify the returned balance, and pass a frontend eligibility check. For governance decisions that determine treasury allocation or protocol upgrades, that is not acceptable.

Verification must happen server-side, with cryptographic proof. The on-chain attestation primitive does exactly this: you send a condition (token, chain, threshold), and get back an ECDSA-signed boolean. The response confirms whether the wallet meets the condition without revealing the actual token count.

Verify UNI holdings for governance

Here is a curl request that verifies whether a wallet holds at least 100 UNI tokens on Ethereum, the minimum for submitting a governance proposal on Uniswap.

curl -X POST https://api.insumermodel.com/v1/attest \
  -H "X-API-Key: insr_live_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    "conditions": [
      {
        "type": "token_balance",
        "contractAddress": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984",
        "chainId": 1,
        "threshold": 100,
        "decimals": 18,
        "label": "UNI >= 100 for governance"
      }
    ]
  }'

One API call. One credit. The response tells you true or false, signed with an ECDSA P-256 key.

Python example

import requests

API_KEY = "insr_live_YOUR_KEY_HERE"
BASE    = "https://api.insumermodel.com"

resp = requests.post(
    f"{BASE}/v1/attest",
    headers={
        "X-API-Key": API_KEY,
        "Content-Type": "application/json",
    },
    json={
        "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
        "conditions": [
            {
                "type": "token_balance",
                "contractAddress": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984",
                "chainId": 1,
                "threshold": 100,
                "decimals": 18,
                "label": "UNI >= 100 for governance",
            }
        ],
    },
)

data = resp.json()
eligible = data["data"]["attestation"]["pass"]
print(f"Eligible to vote: {eligible}")

for r in data["data"]["attestation"]["results"]:
    print(f"  {r['label']}: {'met' if r['met'] else 'not met'}")

The pass field is the only thing you need to gate a vote. If it is true, the wallet meets the governance threshold.

JavaScript example

const API_KEY = "insr_live_YOUR_KEY_HERE";
const BASE    = "https://api.insumermodel.com";

const resp = await fetch(`${BASE}/v1/attest`, {
  method: "POST",
  headers: {
    "X-API-Key": API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    wallet: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    conditions: [
      {
        type: "token_balance",
        contractAddress: "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984",
        chainId: 1,
        threshold: 100,
        decimals: 18,
        label: "UNI >= 100 for governance",
      },
    ],
  }),
});

const data = await resp.json();
const eligible = data.data.attestation.pass;
console.log("Eligible to vote:", eligible);

data.data.attestation.results.forEach((r) => {
  console.log(`  ${r.label}: ${r.met ? "met" : "not met"}`);
});

Multi-token governance

Some DAOs require holdings across multiple governance tokens. You can verify all of them in a single API call by passing multiple conditions.

curl -X POST https://api.insumermodel.com/v1/attest \
  -H "X-API-Key: insr_live_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    "conditions": [
      {
        "type": "token_balance",
        "contractAddress": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984",
        "chainId": 1,
        "threshold": 100,
        "decimals": 18,
        "label": "UNI >= 100 for governance"
      },
      {
        "type": "token_balance",
        "contractAddress": "0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9",
        "chainId": 1,
        "threshold": 10,
        "decimals": 18,
        "label": "AAVE >= 10"
      },
      {
        "type": "token_balance",
        "contractAddress": "0xc00e94Cb662C3520282E6f5717214004A7f26888",
        "chainId": 1,
        "threshold": 5,
        "decimals": 18,
        "label": "COMP >= 5"
      }
    ]
  }'

The top-level pass field is true only when all conditions are met. Each result in the results array has its own met boolean, so you can see exactly which conditions passed and which did not.

Cross-chain governance

Governance tokens do not always live on a single chain. A DAO might have tokens deployed across Ethereum, Polygon, and Arbitrum. Real-world examples of cross-chain token verification show why this matters. With InsumerAPI, you verify all of them in one call by setting a different chainId per condition.

curl -X POST https://api.insumermodel.com/v1/attest \
  -H "X-API-Key: insr_live_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    "conditions": [
      {
        "type": "token_balance",
        "contractAddress": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984",
        "chainId": 1,
        "threshold": 50,
        "decimals": 18,
        "label": "UNI on Ethereum"
      },
      {
        "type": "token_balance",
        "contractAddress": "0xb33EaAd8d922B1083446DC23f610c2567fB5180f",
        "chainId": 137,
        "threshold": 50,
        "decimals": 18,
        "label": "UNI on Polygon"
      },
      {
        "type": "token_balance",
        "contractAddress": "0xFa7F8980b0f1E64A2062791cc3b0871572f1F7f0",
        "chainId": 42161,
        "threshold": 50,
        "decimals": 18,
        "label": "UNI on Arbitrum"
      }
    ]
  }'

All three chains are verified in a single API call for 1 credit. No separate RPC connections, no chain-switching logic, no multi-provider setup.

Adding the JWT bearer token

For governance systems where the voter needs to present proof of eligibility to a downstream service, add "format": "jwt" to the request body.

curl -X POST https://api.insumermodel.com/v1/attest \
  -H "X-API-Key: insr_live_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    "format": "jwt",
    "conditions": [
      {
        "type": "token_balance",
        "contractAddress": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984",
        "chainId": 1,
        "threshold": 100,
        "decimals": 18,
        "label": "UNI >= 100 for governance"
      }
    ]
  }'

The response includes an ES256-signed JWT alongside the standard attestation data. The JWT contains the attestation result and can be forwarded to downstream services, such as a governance contract backend or a voting relay. For how AI agents use this pattern for agent-based governance, see the wallet authentication guide.

Any standard JWT library can verify it using the JWKS endpoint at /.well-known/jwks.json or GET /v1/jwks. This works out of the box with Kong, Nginx, Cloudflare Access, AWS API Gateway, and any other system that supports JWKS-based JWT verification.

Use case: a voter submits the JWT to the governance backend as proof of eligibility. The backend verifies the JWT signature against the public key, confirms the pass claim is true, and allows the vote to proceed. No second API call needed.

What comes back

Here is a sample response for a single UNI governance check:

{
  "ok": true,
  "data": {
    "attestation": {
      "id": "ATST-C9E5A6B7D8F01234",
      "pass": true,
      "results": [
        {
          "condition": 0,
          "label": "UNI >= 100 for governance",
          "type": "token_balance",
          "chainId": 1,
          "met": true,
          "evaluatedCondition": {
            "type": "token_balance",
            "chainId": 1,
            "contractAddress": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984",
            "operator": "gte",
            "threshold": 100,
            "decimals": 18
          },
          "conditionHash": "0x5d3a...",
          "blockNumber": "0x13a1b40",
          "blockTimestamp": "2026-03-06T10:00:00.000Z"
        }
      ],
      "passCount": 1,
      "failCount": 0,
      "attestedAt": "2026-03-06T10:00:01.000Z",
      "expiresAt": "2026-03-06T10:30:01.000Z"
    },
    "sig": "...",
    "kid": "insumer-attest-v1"
  },
  "meta": { "creditsRemaining": 96, "creditsCharged": 1, "version": "1.0", "timestamp": "2026-03-06T10:00:01.000Z" }
}

Key fields:

pass is true only when all conditions are met.
results[].met tells you whether each individual condition passed.
sig is the ECDSA P-256 signature. Verify it against the public key at GET /v1/jwks or the static /.well-known/jwks.json.
expiresAt is 30 minutes from attestation time.
No balance amount appears anywhere in the response. The result is boolean, not a number.

Why server-side matters for governance

Governance votes determine treasury allocation, protocol upgrades, and community direction. Client-side token checks are convenience features. Server-side signed verification is infrastructure.

The ECDSA signature means the result can be independently verified by any party without trusting the DAO's frontend. A voter's eligibility proof is cryptographic, not cosmetic. That is the difference between a governance UI and a governance system.

Get a free API key in 30 seconds

10 free credits. 33 blockchains. No credit card. Start verifying governance token holdings server-side.

View Developer Portal