Stellar Blockchain Case study

Zi Airdrop Playground

A Stellar smart-wallet application using passkeys instead of seed phrases, with atomic asset swaps, liquidity pools and play-based distribution. Winner of Stellar Community Fund Round 11.

Stellar Blockchain

Zi Airdrop Playground Zi Airdrop Playground

Blockchain Application Engineering

System map · Workflow

Public recognition

  • Winner, Stellar Community Fund R11 Public recognition
  • No seed phrase A wallet created with the prompt that unlocks a phone

Wallet path

  1. Passkey

    Device biometrics, no seed phrase

  2. Smart wallet

    A contract account, not a keypair

  3. Sign

    Signature verified on chain

  4. Settle

    Atomic swap, or nothing

Also built

  • Liquidity pools
  • Asset issuance and distribution
  • Play-and-earn and referral workflows
  • Test suite and audit material

Engineering

Stellar · Soroban · Smart contracts · Passkeys · Next.js · TypeScript

Public project · Public recognition

Role
Blockchain Application Engineering
Disclosure
Public project · Public recognition
Links
Product website View recognition

The problem

What the system had to solve.

Every blockchain application asks a new user to write down twelve words, keep them forever, and accept that losing them means irreversible loss. That single step is where most people stop.

For an application whose point is that anyone can play a game and receive an asset, seed-phrase onboarding does not just add friction — it defeats the purpose.

What I owned

The responsibility behind the work.

Built wallet, asset and distribution functionality for a Stellar application using smart contracts for passkey-based wallets, alongside game, referral and swap workflows.

Developed wallet, asset and distribution functionality: passkey-based smart wallets backed by on-chain signature verification, atomic asset swaps and liquidity, and the game and referral workflows that distribute the asset.

Engineering approach

How it was built.

Wallets are created and used through device passkeys rather than seed phrases, with an on-chain contract verifying the passkey signature and acting as the account, because passkeys sign with a scheme conventional accounts do not accept. Asset exchange settles atomically through swaps and pooled liquidity, and distribution runs through games and referrals rather than open claim so it is tied to participation rather than to whoever automates claiming fastest.

Wallet path

  1. Passkey
  2. Smart wallet
  3. Sign
  4. Settle

The seed phrase problem

Why most people never get past step one.

Every blockchain application asks a new user to do something no other software asks: write down twelve words, keep them forever, and understand that losing them means losing everything with no recovery. That single step is where the overwhelming majority of people stop.

For an application whose point is that anyone can play a game and receive an asset, seed-phrase onboarding is not a rough edge. It defeats the purpose.

Two ways to give someone a wallet

Conventional

  1. Install a wallet extension
  2. Generate a seed phrase
  3. Write down twelve words
  4. Understand irreversible loss
  5. Return to the application

Passkey smart wallet

  1. Authenticate with a passkey
  2. Smart wallet created
  3. Ready to transact
The right-hand path uses the authentication people already use to unlock their phone.

The key is held by the device’s secure hardware and used through the same biometric prompt that unlocks the phone. There is no phrase to lose because there is no phrase.

A smart wallet, not an account

What the on-chain contract has to do.

A passkey signs with a different cryptographic scheme than a conventional blockchain account uses. Bridging that gap requires a smart contract that can verify a passkey signature on chain and act as the user’s wallet, which is what makes the whole onboarding model possible rather than merely desirable.

Transaction path

  1. User confirms with biometrics
  2. Device signs with the passkey
  3. Signature verified on chain
  4. Smart wallet executes the operation
The contract is the account. The user authenticates the way they authenticate everywhere else.

Swaps and liquidity

Exchanging assets without a counterparty.

Beyond holding an asset, the application lets users exchange one for another through atomic swaps and pooled liquidity. Atomicity is the property that matters: a swap either completes entirely or does not happen, so there is no state in which one side has been given up and the other not received.

Asset capabilities

  • Atomic asset swaps
  • Liquidity pools
  • Asset issuance and distribution
  • Wallet balances and history

Atomic settlement is the whole reason to do this on a ledger rather than in a database. Remove it and the trust assumptions come back.

Distribution through play

An airdrop people earn rather than claim.

Distributing an asset by open claim rewards whoever automates claiming fastest. Distributing it through games and a referral structure ties distribution to participation instead, which is a different design problem: the reward path has to be resistant to being farmed while still being genuinely open.

Distribution surface

  • Classic games
  • Play-and-earn rewards
  • Referral rewards
  • Asset distribution to smart wallets

Testing and audit

Software that moves assets has a different bar.

On-chain code cannot be patched the way a web application can, and a mistake moves real value. The project carries an automated test suite and security audit material alongside the implementation rather than treating either as something to add if there is time.

What that includes

  • Automated test suite
  • Security audit material
  • Documented operational procedures

Engineering scope

What I worked on.

  1. Passkey smart wallets without seed phrases
  2. On-chain passkey signature verification
  3. Atomic asset swaps and liquidity pools
  4. Play-and-earn and referral distribution
  5. Wallet balances and transaction workflows
  6. Test suite and security audit material

Why these decisions mattered

The trade-offs behind the wallet.

  • Passkeys instead of seed phrases

    Decision
    Wallets are created and used through device passkeys.
    Why
    Seed-phrase onboarding is where non-technical users stop, which defeats an application built for them.

  • A smart contract as the wallet

    Decision
    On-chain contract verifies passkey signatures and holds the account.
    Why
    Passkeys sign with a scheme conventional accounts do not accept; the contract is what bridges it.

  • Atomic swaps

    Decision
    Exchanges settle atomically or not at all.
    Why
    Partial settlement reintroduces exactly the counterparty trust a ledger exists to remove.

  • Distribution through participation

    Decision
    Assets are earned through games and referrals.
    Why
    Open claim rewards automation; participation ties distribution to actual users.

  • Audit material alongside the code

    Decision
    Tests and security review treated as part of the deliverable.
    Why
    On-chain code cannot be hot-fixed, and the failure mode is loss of value.

Impact

What the design achieves.

A wallet a non-technical person can create and use with the same biometric prompt that unlocks their phone, with no seed phrase to lose, and asset exchange that settles atomically or not at all.

Technology

The technical surface.

  • Stellar
  • Soroban
  • Smart contracts
  • Passkeys
  • Next.js
  • TypeScript

Next: Fluence

Back to all work Start a conversation