Protocol 21 Upgrade on Stellar Brings Enhanced Security with Passkeys


Builders can now leverage encrypted data stored on hardware to support security layers with biometrics to sign transactions

By: Stellar Loading...

Protocol 21 Upgrade on Stellar Brings Enhanced Security with Passkeys

On June 18th, 2024, Stellar public network validators voted to upgrade the network to Protocol 21, which activates five new Core Advancement Proposals (CAPs) on the Stellar Mainnet.

The five CAPs introduced in Protocol 21 allow for some neat features, including an improvement to state archival, a few overall cost improvements to smart contract transactions, and perhaps the most exciting, native support of secp256r1 verification in smart contracts, enabling passkey signing support. The Stellar Development Foundation has built out a web app where you can demo passkeys to build a smart wallet.


AP-0051: Smart Contract Host Functionality: Secp256r1 Verification

The secp256r1 signature scheme is an elliptic curve commonly used in WebAuthn, which is the standard behind passkeys available on browsers, computers, and phones. Enabling secp256r1 verification allows developers to design contracts that incorporate passkeys to sign smart contract transactions and access accounts instead of using seed phrases or signing keys.

Passkeys offer a faster, more secure method of identity authentication by using encrypted data stored on a device and performing user verification with hardware tokens (like YubiKeys), biometric data (like fingerprints or facial recognition), or other cryptographic methods. The ability to use passkeys to sign transactions and access accounts removes the need for users to remember their secret keys or 12- to 24-word seed phrases, something that has been a massive barrier to entry for blockchain.

New Core Advancement Protocols (CAPs) Added in Protocol 21

Although not as splashy as passkey support, these four CAPs do much to ensure the efficiency and cost-effectiveness of the Stellar network.

CAP-0053: Separate host functions to extend the TTL for contract instance and contract code

Before Protocol 21, smart contracts on Stellar only had one host function that extended the time to live (TTL) of the contract code and contract instance ledger entries by the same value. CAP-0053 introduces two new smart contract host functions: `extend_contract_instane_ttl` to extend the contract instance’s TTL and `extend_contract_code_ttl` to extend the contract code’s TTL. With these two host functions, the user can extend the contract instance and the contract code separately, improving rent fee distribution.

Not only does CAP-0053 improve state archival functionality, but it was also created by Stellar community member Tommaso De Ponti (tdep)!

CAP-0054: Soroban refined VM instantiation cost model

Before Protocol 21, CPU costs were linked to transaction fees and were primarily from virtual machine (VM) instantiation. This CAP introduces a refined model that aims to charge fees that are closer to reality rather than overestimations, which lowers overall costs and enhances network scalability.

CAP-0055: Soroban streamlined linking

This CAP lowers the total cost by linking to fewer host functions during VM instantiation. There are over 100 host functions, and prior to Protocol 21, all host functions were linked for every contract. CAP-0055 reduces these links to only the functions explicitly imported by the contract, lowering CPU costs per transaction, permitting more transactions per ledger, and boosting overall network performance by decreasing unnecessary workload.

CAP-0056: Soroban intra-transaction module caching

This CAP lowers total costs by caching parsed Wasm modules within a smart contract transaction. Before Protocol 21, if a smart contract transaction invoked the same contract multiple times, each invocation re-parsed the contract. Introducing a module cache means contracts only need to be parsed once per transaction, regardless of how many times they are invoked. This change allows for more transactions per ledger, improves throughput, and enhances performance by eliminating redundant parsing within a transaction’s contract invocation tree.

Next Steps

It’s an exciting time to be building on Stellar. Having passkey support on a technically advanced L1 network with native account abstraction and low-cost, short-term data storage (state archival) opens up doors to creating highly usable, efficient, and secure projects.

So play around with the passkey examples, build something yourself, and share your findings in the #passkeys channel in the Stellar Developer Discord. Let’s bring a secret key-less and seed phrase-less future to blockchain together!