Blockchain can record the activity of every wallet, but cannot determine just from an address: are ten wallets held by ten different people, or all by the same person.
This isn't an issue in regular transactions, but becomes a challenge during airdrops, reward claims, or community votes: the rule states 'once per person', but what smart contracts can actually identify is only 'once per address'. By constantly switching wallets, the same person could participate repeatedly.
On the evening of July 28th, Base's developer official account Base Build announced the launch of Base Verify Onchain. This feature attempts to solve the aforementioned problem: applications can write rules like 'only one participation per verified identity' and 'only users meeting specific conditions can participate' into their smart contracts. Currently, Base Verify Onchain is operational on the Base Sepolia testnet.
What is Base Verify Onchain?
Simply put, Base Verify Onchain is a verification mechanism that connects off-chain identity qualifications with on-chain contract rules.
It does not allow smart contracts to directly access a user's X, Instagram, TikTok, or Coinbase accounts. Instead, Base Verify's off-chain service first checks if the user meets the conditions, then issues a short-term valid verification result; the smart contract subsequently verifies this result on-chain and decides whether to allow the user to claim, deposit, mint, or vote.
The complete process can be divided into four steps.
Step one, developers pre-define the qualification rules in the smart contract, namely a credential provider and one or more conditions. For example, an application could require users to have a verified X account, an X follower count reaching a certain threshold, or a valid Coinbase One membership.
Step two, the user connects their wallet and signs an SIWE (Sign-In with Ethereum) message pointing to the application's contract. The application sends this message along with the wallet signature to the Base Verify API.
Step three, Base Verify's off-chain service first verifies the user-signed SIWE message and recovers the signing wallet address from the signature. It then reads the provider and conditions pre-set by the contract the message points to, and compares these conditions against the verified credentials this wallet has stored with Base Verify. Only when the user satisfies all conditions will Base Verify issue a short-term valid EIP-712 verification, returning a hash value (identityHash), expiration time, and verification signature to the application. This hash is a one-way hash used to identify and deduplicate the same verified identity.
Finally, the application submits these three pieces of data to the smart contract. The contract checks if the signature is from a trusted signer, if the verification has expired, and if the verification matches the current chain, contract, and qualification rules. Upon passing these checks, the application contract then queries whether the identityHash has already been used: if the same verified identity has participated before, even if using a different wallet this time, it will generate the same identityHash and thus be rejected by the contract.
Two distinct stages must be clarified here: whether the user meets the qualification conditions is judged by Base Verify's off-chain service; whether the signature is valid, expired, corresponds to the current contract rules, and whether the identity has already participated, is checked by the on-chain contract. The user's social media username, follower data, or membership information is not directly written on-chain as a result.
identityHash is also not a unified identity number that can track a user across all applications. It depends simultaneously on the verified identity and the application contract: the same identity using different wallets with the same contract will generate a consistent hash; when interacting with another contract, the hash will change. Therefore, different applications cannot directly correlate the same user solely based on identityHash.
It Solves Eligibility Enforcement, Not a Universal Identity System
The core problem Base Verify Onchain solves is: how can smart contracts reliably enforce 'who can participate' and 'how many times can the same identity participate?'
It is suitable for on-chain scenarios with clear rules, such as airdrops where one person can only claim once, reward events limited to specific users, and voting, minting, deposit, or claim processes that need to reduce interference from multiple wallets. The official test page currently shows two examples: users can complete verification via 'a valid Coinbase One membership' or 'a verified X account', and claim a test airdrop once on Base Sepolia.
It's important to note that Base Verify Onchain is not a general-purpose identity system capable of proving a user's name, nationality, or other legal identity, nor is it KYC. Successful verification only indicates that a certain verified identity meets the conditions pre-set by the contract. The contract will not thereby know specifically who the user is, nor should it infer the user's personal details based on this.
Is the Base Airdrop on the Agenda?
The announcement of Base Verify Onchain naturally leads to thoughts of a Base token and a potential airdrop. If distributing on-chain rewards to real users becomes necessary in the future, it could indeed provide a technical tool to prevent duplicate claims across multiple wallets.
Meanwhile, Base had already confirmed at BaseCamp in September 2025 that it had begun researching the possibility of issuing a network token. However, the official statement at the time clearly indicated that related work was still in early exploratory stages, with no release timeline, token design, or governance arrangements announced.
Currently, Base Verify Onchain appears more like Base filling a gap in its identity verification and anti-duplicate-claim infrastructure, rather than starting an airdrop countdown. If Base issues a network token in the future and chooses to distribute it to users, this toolset could indeed be used to screen eligible participants and limit duplicate claims by the same identity.
