AlgoKit-Core Mobile SDKs | June 2026 release (proposal #3618757149)

michaeltchuang · June 27, 2026, 3:19am

Let’s discuss my proposal - AlgoKit-Core Mobile SDKs | June 2026 release

xGov proposal - AlgoKit-Core Mobile SDKs | June 2026 release | xGov

Originally started by the Algorand Foundation (AF) to create multi-language SDKs from a unified Rust core using RustFFI, the algokit-core project was handed off to the community when AF narrowed its focus to TypeScript and Python.

The algokit-core working group was formed to try to fill a critical gap: bringing feature-complete, native mobile SDKs (Android & iOS) to the Algorand ecosystem, ensuring parity with the web SDKs. Additionally, this working group serves as an experiment in decentralized, community-led protocol maintenance for Algorand’s long-term sustainability.

We successfully built (in this release) the rust base and then used FFI to generate and publish native mobile packages to Maven (Android) and SPM (iOS).

These core crates are powering a downstream native mobile wallet:

algokit-crypto: Account creation and recovery (Algorand standard & HD accounts)
algokit-transact: Transaction encoding and decoding
algokit-composer: Asset transfers, ASA opt-ins, key registration, etc.

We are requesting 88,888 ALGO in retroactive funding for two months of high-intensity development (May – June 2026) for this deliverable. The requested funding will be reinvested in future quarters to continue building out algokit-core. Roadmap-wise, our next release will cover updating the OAS generator (used to generate algod client & indexer related crate code in rust)…and to research if we can do the same for Kotlin/Swift.

We will also will look into supporting native Falcon accounts after that in algokit-core. In the meantime, there is an Android/iOS SDK for Falcon lsigs currently you can use ( GitHub - algorandecosystem/falcon-signatures-mobile: Go mobile wrapper SDK around falcon-signatures CLI (until official mobile SDK support) · GitHub )

About the Team

The AlgoKit-Core working group consists of David Rojas, Michael T Chuang, and Joe Polny (sometimes Michael Feher also joins in).

David Rojas (Former AF AlgoKit Tech Lead)
Michael T Chuang (Former AF Android Tech Lead). Michael T Chuang currently serves as a member of xGov Council and will abstain from voting on this proposal within xGov Council to prevent conflict of interest.
Joe Polny & Michael Feher (Current AF Engineers contributing in their spare time)

Financial Transparency: Contributions from active Algorand Foundation employees are considered covered by their salaries. 100% of this grant goes exclusively to the non-AF independent builders in the working group to sustain dedicated development

Additional Info:

Repos
algokit-core repo: GitHub - algorandecosystem/algokit-core: Rust implementations of core Algorand functionality that is exposed to other languages via FFIs. · GitHub
iOS SPM distribution repo: GitHub - algorandecosystem/algokit-core-swift: AlgoKit-Core Swift Distribution Repo (Read-Only) · GitHub
maven Android distribution link: Maven Central: io.github.algorandecosystem
falcon-signatures-mobile repo: GitHub - algorandecosystem/falcon-signatures-mobile: Go mobile wrapper SDK around falcon-signatures CLI (until official mobile SDK support) · GitHub

Metrics:
146+ unique repo cloners, 1,062+ repo clones (github traffic last 14 days | algokit-core)
27+ unique repo cloners, 31+ repo clones (github traffic last 14 days | algokit-core-swift)
44+ unique repo cloners, 82+ repo clones (github traffic last 14 days | falcon-signatures-mobile)

uhudo · July 5, 2026, 8:49am

Thank you for your continued innovation on multiple fronts!

To start of the proposal discussion, below are some of my thoughts:

Within the Council we have been discussing that the proposal should be open-sourced for some time (e.g. min. 2 months) before being eligible for a grant, in order to ensure the code has been battle-tested. While this has been merely a suggestion at the moment, I think it carries merit and would be good to apply even for such improvements to existing repos.
The xGov program has a one-proposer-one-proposal-at-a-time limitation, which is being bypassed here by having multiple members propose different proposals for the same entity (i.e. 3618757149 and 3622469239). While the limitation is not and cannot be strictly imposed, I am conflicted about whether this is the spirit of the current xGov program.
The two submitted proposals have overlapping development timeframes and both state high-intensity development. Could you clarify more specifically what high-intensity means?
The community previously funded with 120k ALGO one year of support for .NET Algorand SDK, which reported 20k downloads. It would be interesting to hear if the work of the two proposals can be compared.
The situation regarding the contributions, the team and ownership is not completely clear to me. The proposals describes Current AF Engineers contributing in their spare time and Contributions from active Algorand Foundation employees are considered covered by their salaries., which reads to me as if AF salary is covering their spare time activities. The whole situation with AF employees being involved seems conflicting with T&C Section 16.1(j)(i). To simplify the situation, I would suggest reformulating the proposal as coming only from non-AF members and just stating what were the teams’ contributions to the delivered work.
Content-wise, it is unclear to me whether the proposal covers work only on https://github.com/algorandecosystem/algokit-core or also https://github.com/algorandecosystem/falcon-signatures-mobile, which is provided as part of the metrics.
As xGov currently funds only retroactive work, I would suggest removing the future promises from the proposal and/or moving it under Additional Info section.

michaeltchuang · July 7, 2026, 4:01am

@uhudo Answers to your questions/thoughts…

Within the Council we have been discussing that the proposal should be open-sourced for some time (e.g. min. 2 months) before being eligible for a grant, in order to ensure the code has been battle-tested. While this has been merely a suggestion at the moment, I think it carries merit and would be good to apply even for such improvements to existing repos.

In January 2026, the algokit-core repo was already open-source when it migrated to the (community-led) AlgorandEcosystem org. We published the first Swift Package Manager distribution repo and MavenCentral binaries in early June 2026 for this proposal. A live Android/iOS wallet fully integrated the SDK and has been running it in production since mid-June.

Just to clarify your opinion/stance, are you suggesting a repo or the last release deliverable in a proposal have to wait two months (in open source) before asking for funding? Keep in mind, a proposal currently already has 2 weeks of discussion, 2 weeks of voting, and more than 2 weeks of waiting to be funded. How does open-source after the vote case work then?

The xGov program has a one-proposer-one-proposal-at-a-time limitation, which is being bypassed here by having multiple members propose different proposals for the same entity (i.e. 3618757149 and 3622469239). While the limitation is not and cannot be strictly imposed, I am conflicted about whether this is the spirit of the current xGov program.

I personally think it’s okay for xGov because each proposal is for different projects and there is no overlap in work (one is app level, the other is SDK level). My hard stance as an xGov Council member is no double payment by xGov for the same scope of work. This is clearly not the case.

If a talented team can contribute to many different projects at the same time and deliver results, I believe that should be firmly rewarded and not frowned upon in xGov. When a team works on two different big projects, my opinion is two proposals should be sent up instead of lumping them together where xGov members can’t vote on approving one, but not the other. For example, TxnLab shouldn’t have to combine a reti and use-wallet proposal just because partial members are from the same team.

The two submitted proposals have overlapping development timeframes and both state high-intensity development. Could you clarify more specifically what high-intensity means?

By “high intensity,” we mean that certain team members are putting in near full-time hours to hit our milestone deliverables. The dev teams behind each proposal are almost entirely different (I’m the only person on both), which is exactly how we’re able to pull off so much work during overlapping timeframes

The community previously funded with 120k ALGO one year of support for .NET Algorand SDK, which reported 20k downloads. It would be interesting to hear if the work of the two proposals can be compared.

It might be hard to track Android (Maven Central) or iOS (Swift Package Manager GitHub projects) libraries because neither platform tracks or exposes public download totals for a direct comparison.

On a related note, Algokit-core platform is supporting three SDK languages (Rust, Swift, Kotlin) currently in this proposal. The rustFFI approach gives us a chance to add more languages in future (c# could be one, and easier to keep feature parity if we chose this approach), but the algokit-core working group wants to make sure it works for mobile languages first since there are downstream clients battle-testing the generated mobile SDK.

The situation regarding the contributions, the team and ownership is not completely clear to me. The proposals describes Current AF Engineers contributing in their spare time and Contributions from active Algorand Foundation employees are considered covered by their salaries., which reads to me as if AF salary is covering their spare time activities. The whole situation with AF employees being involved seems conflicting with T&C Section 16.1(j)(i). To simplify the situation, I would suggest reformulating the proposal as coming only from non-AF members and just stating what were the teams’ contributions to the delivered work.

That is great feedback, and I can absolutely update the proposal to reflect only non-AF members.

My approach has always been to prioritize transparency by giving credit to every individual who contributed to the final deliverable. In this case, an AF employee contributed in their spare time on a project outside their direct, immediate assignment of their day job (even if they may not care about any financial reward). Since this is the first xGov proposal to encounter this specific dynamic, I wanted to be upfront about it.

I think this highlights an important new edge case for the xGov system though. I would love to discuss this further at the xGov Council meeting this Wednesday if you are able to make it, so we can establish a robust framework for handling similar situations in the future

Content-wise, it is unclear to me whether the proposal covers work only on https://github.com/algorandecosystem/algokit-core or also GitHub - algorandecosystem/falcon-signatures-mobile: Go mobile wrapper SDK around falcon-signatures CLI (until official mobile SDK support) · GitHub , which is provided as part of the metrics.

The proposal covers work on both repositories.

Right now, algokit-core handles only Algo25 and HD accounts. We included the falcon-signatures-mobile repo to provide immediate support for mobile wallets or dApps wanting to work with post-quantum (PQ) lsig accounts (even if it’s not part of algokit-core). Once native PQ accounts are fully integrated into the main algokit-core SDKs (hopefully August 2026 if all goes to plan), the standalone Falcon repo will no longer be required

As xGov currently funds only retroactive work, I would suggest removing the future promises from the proposal and/or moving it under Additional Info section.

We can do that (on xGov website, since it looks like we can’t edit this forum thread’s original post anymore).

Anzus_GemWallet · July 24, 2026, 4:13am

Thanks for working on native Android and iOS support. I’m with Gem Wallet, an open-source multichain mobile wallet supporting Algorand, and mobile SDK coverage is particularly relevant to us.

From a wallet implementation perspective, it would be helpful to understand which production wallet workflows are already considered stable: HD account derivation, ASA opt-ins, atomic transaction groups, rekeyed accounts, key registration, transaction simulation, and signing requests originating from dApps.

Is there a preferred channel for mobile wallet teams to report integration feedback?

michaeltchuang · July 24, 2026, 5:56pm

@Anzus_GemWallet - answers to your questions…

Is there a preferred channel for mobile wallet teams to report integration feedback?

Please feel free to open a GitHub issue for any feedback or feature requests. My team will track and address them directly there

From a wallet implementation perspective, it would be helpful to understand which production wallet workflows are already considered stable: HD account derivation, ASA opt-ins, atomic transaction groups, rekeyed accounts, key registration, transaction simulation, and signing requests originating from dApps.

All of the workflows you listed are currently used by a downstream wallet, so I can confirm they are functional. The only exception is transaction simulation - it isn’t supported in the SDK yet, but it is on the roadmap to be added

in case this helps from a KMP project…kotlin code using the algokit-core sdk

github.com/michaeltchuangllc/algokit-walletsdk-kmp

wallet-sdk-core/src/androidMain/kotlin/com/michaeltchuang/walletsdk/core/algosdk/AlgoAccount.android.kt

main

package com.michaeltchuang.walletsdk.core.algosdk

import android.util.Base64
import com.michaeltchuang.walletsdk.core.algosdk.bip39.sdk.AlgorandBip39WalletProvider
import com.michaeltchuang.walletsdk.core.algosdk.bip39.sdk.Bip39Wallet
import com.michaeltchuang.walletsdk.core.algosdk.domain.model.Algo25Account
import com.michaeltchuang.walletsdk.core.algosdk.transaction.sdk.AlgoKitBip39SdkImpl
import com.michaeltchuang.walletsdk.core.algosdk.transaction.sdk.SignFalcon24TransactionImpl
import com.michaeltchuang.walletsdk.core.algosdk.transaction.sdk.SignHdKeyTransactionImpl
import com.michaeltchuang.walletsdk.core.encryption.domain.utils.clearFromMemory
import com.michaeltchuang.walletsdk.core.foundation.utils.getMinimumFee
import com.michaeltchuang.walletsdk.core.network.model.TransactionParams
import com.michaeltchuang.walletsdk.core.transaction.model.OfflineKeyRegTransactionPayload
import com.michaeltchuang.walletsdk.core.transaction.model.OnlineKeyRegTransactionPayload
import org.bouncycastle.jce.provider.BouncyCastleProvider
import uniffi.algokit_composer_ffi.AssetOptInParams
import uniffi.algokit_composer_ffi.AssetTransferParams
import uniffi.algokit_composer_ffi.CommonTxnParams
import uniffi.algokit_composer_ffi.ComposerParams
import uniffi.algokit_composer_ffi.OfflineKeyRegParams

This file has been truncated. show original

and swift code using the algokit-core SDK

github.com/michaeltchuangllc/algokit-walletsdk-kmp

wallet-sdk-core/src/iosMain/swift/AlgorandIosSdk/spmAlgoApiBridge.swift

main

import Foundation
import MnemonicSwift
import FalconAlgoSDK
import CryptoKit
import AlgoKitCrypto
import AlgoKitComposer
import AlgoKitTransact
import CommonCrypto

@objcMembers public class spmAlgoApiBridge: NSObject {

    @_optimize(none)
    public func getHdPublicKeyFromSeed(seedBase64: String, account: Int, change: Int, keyIndex: Int) -> String {
        do {
            let derivedAccount = try deriveHdAccount(
                seedBase64: seedBase64,
                account: account,
                change: change,
                keyIndex: keyIndex
            )

This file has been truncated. show original

Anzus_GemWallet · July 25, 2026, 3:00am

Thanks for the detailed answer and the Kotlin and Swift examples. It’s helpful to know that the listed workflows are already being used in production, with transaction simulation being the current exception.

I’ll pass the SDK and example repository to our developers so they can assess how it might fit Gem Wallet’s existing architecture. If they identify compatibility questions, missing workflows, or other feedback, we’ll open an issue in the appropriate GitHub repository.

Appreciate you sharing the implementation references.

Topic		Replies	Views
(Android/iOS) Algorand Playground Wallets for Post-Quantum Accounts \| 1 of 4 (xGov Proposal #3409063391) xGov Proposals	7	152	February 12, 2026
(Android/iOS) Algorand Playground Wallets for Post-Quantum Accounts (xGov Proposal #3450339476) xGov Proposals	3	114	February 13, 2026
xGov#199 - AWallet - Retroactive xGov Proposals Pilot xgov , voting-session-4	28	1328	July 17, 2024
Algodot : Algorand SDK in Godot Game Engine xGov Proposals Pilot xgov-proposals	22	308	January 28, 2026
Wormhole NTT Contracts [3546124436] xGov Proposals	20	558	July 4, 2026

AlgoKit-Core Mobile SDKs | June 2026 release (proposal #3618757149)

Related topics