Protocol 21 is Live on Stellar Mainnet

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 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.

Many individuals in the Stellar ecosystem have been working tirelessly on various passkey implemenations — check them out and do your own experimentation with passkeys on Stellar!

Soroban by example is an app that uses passkeys to sign Stellar smart contract transactions.

• Use the app,
• Read the blog,
• Watch the demo,
• View the code,
• Watch the discussion.

Super Peach is a passkey-powered multi-signer abstract account contract example.

• Play with the app,
• View the code,
• Watch the demo.

Passkey Kit is a client-side SDK tool for managing and using passkeys.

• View the code.

Launchtube transaction sponsorship is a service that is currently being tested where devs can send their smart contract transactions to get them funded and submitted to the Stellar Testnet.

• View the code.

Keep up-to-date on all passkey-related information in the Passkey Developer Docs and share your experiences with passkeys in the #passkeys channel in the Stellar Developer Discord.

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, Soroban 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 Soroban 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.

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!