Supporting webauthn on Starknet

WebAuthn is an industry standard specification for accessing Public Key credentials. It defines a set of APIs and interfaces for securely generating keypairs that can subsequently be used for user authentication. The specification is widely supported (Apple, Google, Microsoft) and provides an array of configuration options, each with different usability and security tradeoffs.

In the most usable configuration, platform authentications (Face ID, finger print, ect) provide a simple way for users to securely generate + manage their keypair. Many platforms today include secure elements which can be leveraged through the webauthn api. Passkeys further improve user experience by transparently synchronizing credentials across devices and supporting recovery through the root platform account (i.e. iCloud).

In the most secure configuration, roaming authentications allow specialized hardware to generate credentials and assertions, allowing users to manage their credentials using FIDO2 compliant devices such as Yubikeys or a Ledger (coming soon).

This massive shift in authentication logic is being catalyzed by existing software and hardware providers that represent almost the entirety of the device ecosystem today. Supporting Webauthn credentials allows Starknet to capitalize this momentum, to provide a massive improvement in blockchain usability and, to provide a path for mainstream user adoption.

To summarize:


  • Supported by all major browsers and vendors
  • Platform + Roaming authenticators (FIDO2)


  • Algorithms (P-256, RS256, ect)
  • Extensions (Large Blob Storage)
  • Transports (USB, NFC, BLE, HYBRID, INTERNAL)

User Friendly

  • Platform authenticators generate + manage key pairs securely
  • Key recovery + cross device synchronization done natively (Pass Keys)


The flow generally involves a registration step and subsequent assertion steps coordinated by a Relaying Party.

Note: The registration step does not require any onchain logic. It is facilitated offchain, with webauthn signer being naively initialized with the generated credentials public key or being added as an additional credential through the signing of the transaction by an existing key.

Verifying an assertion

In the Starknet configuration, a smart contract implementation of the webauthn assertion logic according to the specification, which enables the use of webauthn credentials for transaction signing.

At a high level, the logic is required to:

  • Parse a provided client data json blob to verify it matches expectations. Most importantly, verify the challenge value matches the expectation, typically a transaction hash. The validation property is a base64 encoding of the provided challenge bytes, so requires support for either base64 encoding/decoding in starknet.
  • Parse the provided authenticator data and verify it matches expectations. Most importantly, verify the “user present” and “user verified” flags are set.
  • Hash the client data json using sha256.
  • Concatenate auth data + sha256(client data)
  • Hash the concatenation sha256(auth data + sha256(client data))
  • Verify the provided signature matches the expected signature of the hashed data for a given public key.

Current Implementation

At Cartridge, we are eager to unlock the UX affordances provided by Webauthn and have a working implementation of the process described above.

The relevant components are:

What’s missing

There are still a few gaps before we can start using this in production.

At Cartridge, we’re focused on bringing Starknet gaming to mainstream audiences and believe this technology will be critical in achieving that. If you are interested in collaborating, please let us know. Any contributions would be greatly appreciated!


Hello Cartdrige’s team. :wave:

Could you please also explain the [no fee] minting process at contract level?
following the thread at: I could see the use of webauthn during minting, but how do I mint if I am connecting from ArgentX and not from webauth? Was it possible to use ArgentX at
What get me curious is the minting contract paying for users transaction’s fees.

Thanks for your work [and get me curious].


For NFF, we used a multicall to deploy the users account with UDC and mint the NFT to it. The transactions we’re submitted by our wallet, so we covered the gas costs.

Currently ArgentX isn’t integrated with Cartridge, since we are using the newer plugin account interface. We’re considering releasing a Controller plugin that conforms to the old interface as a stop-gap.


Hi ! An optimization that will provide an appreciable speed up is ‘Strauss Shamir’s Trick’. Which should reduce the complexity of signature verification from 2 ecmul (costing 2n DoublePoint, and n AddPoint) to 1.33 ecmul (n DoublePoint and n AddPoint), for a practical gain around 25-30% (estimation). It can be further improved with ‘sliding windowed’ method : Exponentiation by squaring - Wikipedia

Note that this is agnostic from the base field used (dunnow if 256k1 is implemented with the GLV method or not).


Hey @tarrencev; this is amazing work! I work at Nethermind and we would like to support this endeavour! I have passed on the open problems to our research team and our audit team would love to help audit this. Can you DM me your telegram handle?


Very cool! I think this would be a significant improvement and reduce the tradeoffs w.r.t using the native curve. Would very much appreciate any contributions!


Hi! Sid it for 256k1, but is exactly the same algorithm for the generic Starkcurve and P256r1 (webAuthn):

Current gain is around 45%, i shall randomize the test to have a more precise mean value. ec_mulmuladd stands for the operation aP+bQ, where (a,b) are scalar and (P,Q) multiplications. These operation represents most of the signature verification part, both for ECDSA and Schnorr (as used in Taproot, Musig2) signatures.

Gonna PR this for starkcurve, P256r1 and P256k1.


The correct link:

The target function is ec_mulmuladd_W, i did not figure how to avoid code replication to deal with each curve.