Imagine being able to transfer 100 USDC to a GitHub developer who has never used crypto, using nothing more than their GitHub username—not a wallet address. You can even send the funds onchain before they know you've sent them anything.
Yet the funds are already onchain, awaiting their claim. The recipient can claim them as soon as they verify their github identity.
How do you make this possible without taking custody of the funds?
This was one of the engineering challenges we addressed while building P2ID, our Pay-to-Identity Protocol.
Why identity-based payments matter
The idea of paying someone using an identity they already have is hardly new.
PayPal, Venmo, and Cash App have demonstrated how intuitive payments become when people can use email addresses, usernames, or familiar payment handles instead of bank account details.
There's a practical advantage to this approach beyond convenience.
A wallet address is a long hexadecimal string with little meaning to the sender. Even when copied correctly, it offers limited assurance that the destination belongs to the intended recipient.
An email address or social handle, by contrast, is recognizable and easier to cross-check against someone you already know. That can reduce certain kinds of addressing errors, although it doesn't eliminate impersonation or identity-related risks.
If you already know someone's GitHub username, X handle, or email address, why should you need another identifier just to pay them?
This becomes particularly useful for developer rewards, creator payments, community incentives, and applications powered by AI agents. These systems often know the intended recipient's identity long before they know anything about the recipient's wallet.
P2ID brings that familiar payment experience to stablecoins, without requiring recipients to register a wallet address in advance or entrust their funds to a custodial payment platform.
1. Deriving a payment destination before the recipient exists onchain
The first requirement was to establish a payment destination without requiring any action from the recipient.
On Ethereum-compatible networks, CREATE2 makes this possible.
Unlike conventional contract deployment using CREATE, where the resulting address depends on the deployer's nonce, CREATE2 derives an address from the deploying contract, a salt, and the hash of the initialization code.
The resulting address can be calculated before the contract is deployed.
Mathematically:
address = last20bytes(keccak256(0xff ++ deployer ++ salt ++ keccak256(init_code)))
This means a payment application can determine where a future contract will exist without deploying it immediately.
More importantly, ERC-20 tokens can be transferred to that address even when no contract code exists there yet. The token contract simply records the balance against the destination address.
For P2ID, we associate a recipient's identity with a deterministic payment identifier that participates in deriving the destination address.
Conceptually:
Recipient identity → Payment identifier → Deterministic address
The sender transfers stablecoins to that address, and the recipient can subsequently verify their identity and claim the funds through the protocol's authorization mechanism.
There is no requirement for the recipient to have previously registered a wallet.
What about Solana?
Solana provides a related capability through Program Derived Addresses (PDAs).
A PDA is deterministically derived from a set of seeds and a program ID. Unlike a conventional Solana keypair address, a PDA is deliberately derived off the Ed25519 curve, meaning there is no corresponding private key that can sign transactions.
Instead, the owning program can authorize operations involving the PDA through Solana's runtime.
For SPL tokens, the architecture differs from Ethereum because tokens are held in token accounts. A token account must be initialized before receiving tokens, but it can be controlled by a PDA rather than a recipient's personal wallet.
The implementation differs, but the broader principle remains:
A recipient's payment destination can be established independently of their participation.
However, deterministic addressing alone doesn't solve identity-based payments.
It only establishes where funds can be sent.
2. Bridging social identities and smart contracts with zero-knowledge proofs
Deterministic addresses solve where funds can be sent. They don't establish who is authorized to claim them.
Suppose Alice sends 100 USDC to Bob's GitHub username.
When Bob eventually claims the payment, P2ID must establish that he controls the username associated with the payment destination.
The challenge is that blockchains have no native understanding of GitHub usernames, X handles, or email addresses. They can verify cryptographic statements, but they cannot independently authenticate identities maintained by external platforms.
To bridge that gap, P2ID uses zero-knowledge proofs built with Noir.
The recipient first verifies control of the identity associated with the payment. P2ID then generates a cryptographic proof using a Noir circuit that enforces the protocol's authorization constraints.
The smart contract verifies the resulting proof before authorizing the release of funds.
This separates three distinct responsibilities:
Identity verification: Establishing control of the recipient's social identity.
Zero-knowledge proof generation: Proving that the protocol's authorization constraints have been satisfied.
Onchain verification: Validating the proof and enforcing the payment's claim conditions.
The smart contract doesn't need to communicate directly with GitHub, X, or an external authentication service. It only needs to verify the proof against the expected public inputs.
Importantly, zero-knowledge proofs do not automatically make the underlying identity verification trustless. The protocol's security still depends on the integrity of the evidence used to establish identity control.
What they provide is a way to make the authorization process cryptographically verifiable onchain, without exposing every detail of the underlying verification process.
The recipient proves control of an existing identity. The protocol verifies the authorization. The funds are released without Pvium taking custody.
This is one of the architectural decisions that makes P2ID possible: connecting familiar internet identities to permissionless smart contracts without requiring recipients to register a wallet before someone can pay them.
3. Mutable identities: Why we chose usernames over account IDs
One of the more interesting architectural decisions we made in P2ID was how to handle mutable social identities.
A GitHub username can change. An X handle can be transferred or reassigned. An email address can eventually come under someone else's control.
At first glance, this seems to introduce a problem: what happens when a payment is sent to a username that subsequently changes ownership?
Our approach was to treat the username itself as the payment identifier, rather than attempting to permanently associate it with a particular person or provider-issued account ID.
The reasoning comes from a familiar principle in cryptography.
Onchain authorization is based on control, not personal identity.
When a smart contract verifies an Ethereum signature, it establishes that the signer possesses the private key corresponding to an address. It doesn't establish who the signer is, whether the key has changed hands, or whether the person exercising control is its original owner.
The protocol is agnostic to those questions.
We applied a similar principle to P2ID.
A payment addressed to a GitHub username is associated with that username. Whoever can demonstrate valid control of that username under the protocol's verification rules can exercise its claim rights.
If the username changes hands, the protocol doesn't attempt to reconstruct its ownership history or determine who ought to control it.
The identifier remains the same. The party authorized to act on it may change.
This is a deliberate design choice rather than an overlooked edge case.
It avoids introducing a permanent dependency on provider-issued account IDs, which would require an additional identity-resolution layer and complicate payments initiated using only a username.
It also keeps the protocol's responsibility narrowly defined: establish a payment destination from an identifier and enforce the authorization rules governing claims.
There is, however, an important distinction between cryptographic keys and social identities.
A private key is governed by cryptographic control. A username is governed by the policies and security of an external identity provider.
A platform may suspend, recover, or reassign a username. Consequently, the security of a username-based claim depends partly on that provider's authentication and account-management systems.
P2ID doesn't eliminate that dependency. It makes control of the chosen identifier the basis of authorization.
This means senders must understand what they're paying: a username, not an immutable person or account.
In P2ID, identity is a payment destination defined by its identifier and verification rules, not a claim about the real-world individual behind it.
4. Making unclaimed payments refundable
The next challenge was ensuring that funds wouldn't remain inaccessible indefinitely if the recipient never claimed them.
P2ID supports expiring payments, allowing unclaimed funds to be returned to the sender under defined conditions.
This is more complicated than attaching a timestamp to a transaction.
The contract needs to enforce mutually consistent rights for the sender and recipient.
Before expiry, the recipient may be authorized to claim the payment.
After expiry, the sender may become eligible to recover the funds.
The implementation must prevent a payment from being claimed and refunded independently, or from being released more than once.
These conditions should be enforced by the contract rather than depending on Pvium to decide whether a refund is permitted.
The objective is straightforward:
The protocol should enforce the payment's conditions without requiring an intermediary to hold the funds.
There is an important design distinction here as well. An ERC-20 transfer to an undeployed address does not automatically become refundable after a deadline.
Refundability must be explicitly implemented in the contract architecture and supported by the payment's recorded authorization and expiry conditions.
Deterministic addressing makes the destination predictable. It doesn't, by itself, provide escrow, refunds, or recovery.
5. Deterministic doesn't mean trustless
One of the lessons from building P2ID is that eliminating custody doesn't eliminate every trust assumption.
CREATE2 is deterministic.
Smart contracts can enforce authorization and refund conditions.
But when claims depend on identities maintained by external providers, the protocol must still establish how those identities are verified.
Who is authorized to attest that a user controls a particular identity?
What happens if the verification service is compromised?
What happens when its signing keys rotate?
Can an administrator replace those keys, and what safeguards govern that process?
These questions matter because a perfectly implemented smart contract can still release funds incorrectly if it accepts a fraudulent identity attestation.
The objective isn't to describe the entire system as trustless merely because its payment contracts are non-custodial.
It's to minimize the trust required, make the remaining assumptions explicit, and ensure that critical operations are verifiable and appropriately constrained.
For developers working on identity-aware smart contracts, this boundary between offchain authentication and onchain authorization is one of the most important areas to get right.
6. What this makes possible
Once applications can initiate payments using identities instead of recipient-supplied wallet addresses, several workflows become substantially simpler.
An open-source maintainer can reward contributors using their GitHub identities.
A creator can receive stablecoin tips associated with a social profile without first publishing a wallet address.
A community can distribute rewards to members who have never interacted with its payment infrastructure.
An AI agent can initiate payments to recognized participants in a workflow without interrupting the process to request wallet details.
In each case, the application already has an identity associated with the intended recipient.
P2ID makes it possible to use that identity as the starting point of an onchain payment.
The recipient can participate when they're ready, rather than being required to complete onboarding before anyone can pay them.
Closing thoughts
The most interesting part of P2ID isn't CREATE2, deterministic addressing, or any individual smart contract technique.
It's what becomes possible when those primitives are combined with identity verification, cryptographic authorization, and programmable payment conditions.
We've spent years improving the experience of creating and managing crypto wallets.
P2ID addresses a different problem: removing the requirement to establish a wallet destination before initiating a payment.
The sender knows who they want to pay. The protocol determines where the funds go. The recipient proves their identity to claim them.
We're building P2ID as an open protocol at Pvium, and I'll be sharing more about its architecture, security model, and the engineering decisions behind it.
Explore P2ID: https://p2id.org
If you're working on Solidity, applied cryptography, or blockchain protocol design, I'd be interested in your perspective.
Where do you see the greatest security challenges in connecting real-world identities to permissionless smart contracts?