(Android/iOS) Liquid Auth for Algorand Post-Quantum Accounts (xGov Proposal #3450979447)

Governance Discussions xGov Proposals
1

Let’s discuss my proposal - (Android/iOS) Liquid Auth for Algorand Post-Quantum Accounts

Link to proposal - (Android/iOS) Liquid Auth for Algorand Post-Quantum Accounts | xGov

  1. The Request

Here is a link to the repo of our work (app side) - GitHub - michaeltchuangllc/algokit-walletsdk-kmp: KMP version of AlgoKit Wallet SDK
Here is a link to the repo of our work (liquid auth service) - GitHub - algorandecosystem/liquid-auth at falcon24-support

Demo Apps:

Android - https://play.google.com/store/apps/details?id=com.michaeltchuang.walletsdk.demo
iOS - Join the AlgoKit WalletSDK Playground beta - TestFlight - Apple

We’re asking for 100,000 ALGO in retroactive funding to cover two months of intense, focused development (Nov 1 to Dec 31, 2025)…which aligns with our 2025Q4 roadmap and releases v3.202504.2, v3.202504.3, v3.202504.4, v3.202504.5, v3.202504.6, v3.202601.0, and v3.202601.1.

  1. What We Delivered (Results)

In 2025Q3, we released a playground wallet to the (iOS) App Store and (Android) Play Store supporting Post-Quantum (PQ) accounts. Our 2025Q4 goal was to build on this foundation, enabling PQ account support within Liquid Auth (Algorand’s P2P WalletConnect competitor) for use across ecosystem dApps.

Here’s what’s ready to use after our 2025Q4 work:

Mobile PQ Tooling: We updated mobile PQ tooling to support 24 BIP39 words.

Wallet SDK: We added support in our wallet-sdk-core and wallet-sdk-ui libraries for localization, passkeys, liquid auth, and watch accounts. The updated xcframeworks and aar binaries are on maven central.

Demo Apps: Playground Wallets (Android/iOS) are able to scan Liquid Auth QR codes and connect with Liquid Auth service

Liquid Auth Service - https://michaeltchuang-docs.ngrok.dev/ (testnet fork that supports PQ accounts)

  1. Liquid Auth & Post-Quantum Accounts (Why Now?)

PQ accounts deliver immediate technical wins for the network: superior secret key protection (compared to ECC), a 4x boost to TPS, and a higher minimum fee of 0.004A (compared to 0.001A)…which is all beneficial for long-term chain sustainability.

Liquid Auth presentation from Decipher: https://youtu.be/4gU_INrx1Cw?si=3eIYtBeIds70ADNn&t=908
Why Liquid Auth > WalletConnect: Authenticated comms between wallets & apps

  1. Deliverable Wins

A. We extended this work from Pera ( Introducing Liquid Auth in Pera: Decentralized, passwordless Web3 authentication for user-owned identity ) so now you can also create passkeys for github/gmail with a Falcon24 PQ account in our wallet
B. We extended this work from Algorand Foundation (https://liquidauth.com) so now users can send test dApp transactions and sign from a mobile wallet’s Falcon24 PQ account.

The features we built let’s community early adopters play with Liquid Auth using PQ accounts. Now it’s just a matter of integrating into use-wallet next and convincing ecosystem dApps to use this instead of walletconnect.

  1. Our Future Vision (Where we’re trying to go)

The requested funding will be reinvested in future quarters to launch new projects/features that specifically attract and make life easier for Algorand mobile developers. For 2026Q1, we will try to add back Liquid Auth option to use-wallet project and integrate with at least one dApp in mainnet (e.g xGov site). Soon you’ll be able to use PQ accounts on algorand dApps much easier!

Additional Information
We added localization support to our wallet in 2025Q4 as well. Hindi (for Algorand India Summit) and Italian (Algorand’s has a rich Italian history due to Silvio). You can use our new screenshot test tool to see all the new flows ( AlgoKit Wallet SDK - Screenshot Gallery )

About the Team

Tony Chuang is a team member at Michael T Chuang LLC helping with Algorand related projects. He’s submitting this project on behalf of the team led by Michael T Chuang, who has a decade of mobile development experience. A couple of other part-time volunteers/contractors also assist at Michael T Chuang LLC on this project when they have time to help.

Metrics:
100+ unique repo cloners, 600+ repo clones

10+ wallet app users playing with PQ accounts

Note:
The amount is 100,004 Algos on xGov website…it’s a typo when Tony created proposal on xGov website (and I can’t edit amount once created), but 4 algos is not worth recreating another proposal since fees are 100A alone

2

hi, btw do we have discussion that post quantum accounts are not very usable on algorand at the moment? when i get the list of transactions to sign, at the moment it adds other transactions to the group prevents efficient smart contract usage if I understand correctly.. also the AF at the last community call said that the quantum secure accounts are not official thing and a lot may change.. that is the reason why i do hasitate to add the non official libraries and not supported product to the Biatec Wallet..

however I think that this quantum secure accounts should be in the research and I hope the Algorand’s CTO will show up and start promoting it and making it official when it will be in good enough quality

for this proposal I am in favor as any development towards the quantum security is very good approach

1 Like
3

scholtz
for this proposal I am in favor as any development towards the quantum security is very good approach

Thanks for your support on this proposal

Most of my team’s work is for early adopters for sure and subject to change in the future, but the one silver lining (after building support for PQ accounts in Liquid Auth) I’ve recently discovered is Falcon-1024 is so different from ED25519…by adding Falcon support to it, I’m essentially paving the way for ecosystem tools like Liquid Auth and Use Wallet to become potentially cross chain (once you add one different encryption algorithm type, the next one is much much easier because foundation is in place)

1 Like
4

@michaeltchuang I see you have two proposals opened at the same time, this is circumventing the “one proposal per proposer” enforced by the Registry. Why is that?

5

cusma

@michaeltchuang I see you have two proposals opened at the same time, this is circumventing the “one proposal per proposer” enforced by the Registry. Why is that?

@cusma It’s two different proposers, not one (e.g. two different human KYC’d xGov accounts, each submitting their own respective proposals)…so my team is not circumventing anything in the xGov registry? They just used the xGov website. I’m not sure what you mean by your question

On a related note, I do think it’s worth getting clarification (in terms and conditions) where AF will draw the line when we have multiple people working together on a project though. We can discuss it here, or maybe at the next AF/Council meeting.

It’s two different clear deliverables so I suggested my team to not combine proposals when submitting (e.g. so a 100K and 200K ask vs one 300K Algos). The total combined amount is also less than other several current proposals asks (400K Algos). This is no different if John (from TxnLab) puts up a proposal for use-wallet improvement work and then Patrick (also from TxnLab) does one for Reti at same time. As a builder, I don’t think we should combine different project milestone/deliverables in general (easier for members to vote on too)

Now that xGov frontend code is open source…Uros, MG, and I as devs might all send in proposals in future for potential improvement work…does this mean only one of us at a time can submit even though we’re all different humans with our own accounts, etc. We all know each other, on the council together, and also have our own projects we’re working on…I’m just clearing the way for this situation that I foresee happening in order to make xGov system more robust. My team can always pull this proposal if there is an issue (and send it next batch)

6

@michaeltchuang the “circumventing” wording was a bit unfortunate, I didn’t meant to accuse you, apologize.

I wanted to point out what seemed to me like 2 proposals from the same author (I understand this is technically from 2 different accounts).

If this becomes acceptable we should rather decide to remove this restriction and let anyone have as many pending proposals as they want rather than having a weak on-chain policy. But we can discuss this on a separate thread/channel. I don’t want to hijack the proposal discussion.

1 Like