Exploring Native Ed25519 Verification in Clarity (Solana, SUI, Near, ...) Cross-Chain Integration

Hi Everyone,

I’m exploring how users from other chains - starting with Solana - can participate in our prediction markets (on BigMarket.ai) wit the least amount of friction and trust assumptions - e.g. I want them to be able to buy prediction shares, claim winnings etc using only their familiar Phantom wallet.

At a high level, the current solutions for cross chain use cases like this, require the Solana user to;

a) deposit funds on Stacks
b) authenticate with a clarity smart contract
c) authorise the contract call - eg buy shares in Market X

The Problem

Step a) has some difficulty around moving the users deposit from a wallet into an on-chain vault but this is outside the current scope.

This current solutions for b) and c) look like this;

> Solana User Action
> Messaging Layer (e.g. Wormhole)
> Guardian Verification
> Off-chain Relayer
> Clarity Contract

Where both the Guardian verification and attestation layer and the ‘off-chain relayer’ carry trust assumptions and complexity and overall, increase the attack surface area of the application.

Proposed Solution:

Native ed25519-verify support in Clarity

A native function such as:

(ed25519-verify message signature public-key)

could enable a much simpler flow:

Solana User Signature
→ Stacks Transaction
→ Clarity Contract
→ Native Verification
→ Contract Action

Why this could matter:

Broader interoperability:

  • Solana

  • Sui

  • Aptos

  • Near

  • Other Ed25519 ecosystems

Potential use cases:

  • Cross-chain prediction markets

  • DAO voting

  • Identity/authentication

  • Wallet interoperability

  • Delegated execution

  • Trust-minimized governance


Why not just use Wormhole / bridges?

Bridges can move assets, but they do not solve native user authentication without additional trust layers.

Stacks already has strong secp256k1 support, but Ed25519 support could unlock entirely new categories of direct cross-chain participation.

Curious to hear thoughts from:

  • Core contributors
  • SIP authors
  • Clarity devs
  • Cross-chain builders
  • Solana / Stacks ecosystem participants

Would love feedback.

3 Likes

Really like this direction, and ed25519 in Clarity is a clean primitive to have regardless. Two pushbacks worth airing though @mikecohen.id

First, this solves authentication, not value transfer. A Solana user can sign a Stacks tx natively, but their SOL or USDC still has to get onto Stacks somehow — which means an onramp through Bitcoin, sBTC, or a bridge. So in practice this is an integration facilitator that removes the relayer/guardian middlemen on the auth layer, but the asset side still has the same trust and friction problems we have today. Worth being precise that this is half the puzzle, not the whole one.

Second, and more importantly, removing friction only matters if there’s a compelling reason to be on Stacks in the first place. If BigMarket is genuinely the best prediction market a Solana user can access, they’ll tolerate friction to get there — bridges, new wallets, all of it. Users crossed worse chasms for Hyperliquid. If the pull isn’t strong enough to overcome friction today, smoothing the UX won’t change the outcome; it’ll just make the empty room easier to walk into. So the proposal makes most sense paired with a clear answer to “why Stacks” — Bitcoin settlement, sBTC liquidity, something the user can’t get on their home chain.

That said, I’m in favor. Native ed25519 lowers the cost of every future cross-chain experiment, and the smart-wallet implications are huge: a Stacks account abstraction contract could register a Phantom pubkey as an authorized signer the same way we register passkeys today, and suddenly one vault is controllable from any ed25519 chain’s wallet. That composability is worth the SIP on its own.

2 Likes

Thanks for the thoughtful comment @Rapha23. I agree this requires a bridge to handle the deposit and that part is outside the scope of this change. I also agree that authorisation via a pubkey managed in Phantom wallet in clarity contracts is much bigger than our specific use case.

1 Like

Ps this issue has been raised on stacks-core and can be tracked there..

1 Like

This also enables XRP ecosystem.
In addition to secp256k, Clarity has support for secp256r as well.

1 Like

I’ve had the chance to collaborate with you in the past. It’s always a pleasure, live or async ser. Also s/o to you for the Bitcoin Clarity lib! Today live and in use at fakfun.com and jingswap.com