Algonaut: the Rust SDK for Algorand (xGov Proposal #3685107518)

Governance Discussions xGov Proposals
1

xGov proposal: algonaut: the Rust SDK for Algorand | xGov
Repository: GitHub - manuelmauro/algonaut: A rusty sdk for Algorand. · GitHub

Summary

algonaut is the community Rust SDK for Algorand. This proposal requests 128,000 ALGO in retroactive funding for approximately 320 hours of development and maintenance across the project’s lifetime, from its first commit on 29 September 2019 through the v0.9.0 release on 11 June 2026. The crate has been published on crates[.]io since March 2021 and has never received ecosystem funding of any kind.

Scope of work

2019 to 2022, v0.1.0 through v0.4.2 (approximately 150 hours)

Initial architecture and the split into a multi-crate workspace: core domain types, ed25519 and BIP-39 mnemonics, transaction builders, and clients for algod, kmd and indexer. The crate reached 0.4.2 in October 2022 and drew about 14,000 downloads over that line.

2022 to 2024, maintenance (approximately 20 hours)

Dependency and security updates, issue triage, and community PR review.

May to June 2026, v0.5.0 through v0.9.0 (approximately 150 hours)

A ground-up modernization: 117 commits, 97 merged pull requests, five releases.

  • v0.5.0 Rust 2024 edition (MSRV 1.85); ring replaced with ed25519-dalek, so wasm32 builds need no C toolchain; workspace-wide dependency refresh; lefthook and make ci.
  • v0.6.0 simulate and dry-run request builders, a TEAL V3 source-map decoder, and domain types that serialize to both JSON and msgpack.
  • v0.7.0 Identifier newtypes (AppId, AssetId, TransactionId) at the client boundary, block, account-resource and ledger-delta endpoints, msgpack response decoding.
  • v0.8.0 An open, async Signer trait, so HSM, remote KMS and WalletConnect implementations drop in as Arc<dyn Signer>; a typestate AtomicGroupBuilder that makes a malformed transaction group a compile error; per-client Cargo feature gates with rustls as the default TLS backend; structured errors with full source chaining.
  • v0.9.0 A contract! proc-macro that reads an ARC-56 Extended App Description at compile time and generates a fully typed client: a deploy constructor that compiles the spec’s TEAL, typed struct, tuple, array, reference and transaction arguments, global, local, box and map state readers decoded per their declared ARC-56 types, ARC-28 event decoding, literal and sourced argument defaults, and a read-only simulate path. ARC-4 clients come from a plain ABI JSON via the same macro.

Additional info

Metrics

  • 17,651 lifetime downloads on crates[.]io
  • 11 published releases, v0.1.0 through v0.9.0
  • 70 stars, 37 forks, 14 outside contributors

Standards

ARC-4 ABI method calls and type encoding, ARC-28 event decoding, ARC-56 Extended App Description consumed at compile time, TEAL V3 source maps, and msgpack canonical transaction encoding compatible with the reference implementations.

License

Dual MIT and Apache-2.0, the Rust ecosystem convention, which is what allows algonaut to be vendored into commercial and regulated contexts.

Prior funding

None, in six years, from xGov or any other source. There is no prior award for this proposal to overlap with.

Happy to answer questions here!

Update

Your post was flagged as spam: the community feels it is an advertisement, something that is overly promotional in nature instead of being useful or relevant to the topic as expected.

My first two posts were flagged as spam by a community member and I am happy to address their concern. Please, feel free to share more details on the parts that made you feel this way and I will edit them accordingly. I am afraid that I won’t be able to address their concerns without additional information.

2

That is supper great work you are doing there.

Do you think it would be possible to create the client generator for rust apps, so that they can from the arc56 generate the client library? something that is like in DotNet or in algokit for Go and Typescript.. I could generate the libraries for all projects in ARC56Registry also in rust and upload to crates.io , so that when you need to swap the assets at dex or use other contracts the poeple are not limitted to the language they use and use old fashion manual mapping of args in the methods.

May I suggest that you adjust the versioning of the rust algosdk to the algod version, so that it is clear that usage is compatible with specific algod version? For example I assume that version 0.9.0 is not compatible with the falcon native accounts as it is 2 months old now and 5.0.0 was released just recently..

Also have you noticed that with Xarmian we are rewriting the algod to rust? Perhaps you might be interested to cooperate on this one as well..

And btw, I believe the 128k algo for the work you have done is too low.. The IT experts time should be valued more.

3

Hi @scholtz ! Thank you for your message!

Concerning the ARC56 support, please take a look at this PR and example:

It should be all you need. If you get to play with this, feel free to open issues on algonaut with any bug you might encounter. It is recent work and would profit from more extended real-world testing. You registry seems a great fit for that!

It’s great to hear that you’re working on a Rust rewrite of algod! I’ll keep a closer eye on that.

Update

Your post was flagged as spam: the community feels it is an advertisement, something that is overly promotional in nature instead of being useful or relevant to the topic as expected.

My first two posts were flagged as spam by a community member and I am happy to address their concern. Please, feel free to share more details on the parts that made you feel this way and I will edit them accordingly. I am afraid that I won’t be able to address their concerns without additional information.

4

Could you point to live use cases you do not own that utilize this SDK?

Rust has 1%~ of Market Share — theoretically you could say out of 100 developers that Algorand obtains, 1 of those will prefer a Rust SDK.

Do you feel this SDK is in a place where you could, confidently, advise someone to use it in place of the latest Python and/or Typescript SDK’s for modern development?

There are also, for some reason, duplicative efforts in developing a Rust SDK — Ludo & Xarmian as well as yourself (not accounting your 14 historical contributions). Have you inspected their source code to find gaps on their end or yours?

There have been 4 or 5 questions about the Rust SDK in the last 3 years on the Algorand discord in the Rust SDK channel, all of them went unanswered. I have not checked to see other sources where discussions may have occurred.

I’m conflicted with the idea of having two obscure libraries, built with significantly less resources than the two flagship SDK’s built by AF Engineers, being funded not once, but twice for $12,000 to $20,000 each at current algo price— considering Ludo’s comment that he recommends you ask for more, which he will likely do as well.

I recall mention of a scorecard being developed for grading proposal value and potential for xGov council re-election, I presume (and hope for the former) we will see both of these things happen first before a council member contributes to the conversation, unless they have a genuine interest.

I’d also like to confirm the proportion of contributions, specifically as you are the one requesting funding, what % of the code base was written by others, and if a significant %, are they included in or aware of the proposal?

Lastly, I think it’s awesome that a community got together and built an SDK for a language on their own. I hope you understand my commentary, as now one person is stepping forward to claim a reward for work done. (And then another two developers again later with another Rust SDK apparently)

In an ideal world you and they would band together to consolidate features developed, but I understand that’s asking a lot. I won’t expect you to do that, but I will say whatever features listed for your Rust SDK, if paid out in this proposal, should not be paid out a second time in the next Rust SDK. Especially considering that your Rust SDK has been open-sourced this entire time. This is my personal opinion, that I also expressed on another proposal recently. Although features that are not unique can be critical to the infrastructure of the Dapp, library, etc., should they be considered if already open-sourced and funded in the past. Just providing context on where I’m coming from, it’s not something that’s officially stated anywhere.

Anyways, looking forward to your response @gedl , appreciate the work and efforts.

6

Hi @Atsoc1993 , thank you for your questions! Taken in order.

Rust’s share. I’d argue the causation runs the other way. Rust is the most-used language across the blockchain ecosystem at large, and it has led Stack Overflow’s most-admired ranking for close to a decade. It is under-represented on Algorand specifically because Algorand has never had an official Rust SDK and the Foundation has never funded one. “Few Rust developers here” is the symptom, not the reason.

Would I recommend it over the Python or TypeScript SDKs? For a greenfield dapp, no: use TypeScript or Python. They have Foundation engineers and AlgoKit behind them, and I’d be doing a new developer a disservice by saying otherwise. If you’re already in Rust, writing a node, an enclave, a wasm32 client or an HSM-backed signer, then algonaut is the only thing you can cargo add, and as of 0.9 it generates a typed client from an ARC-56 app spec. Open gaps, on the record: anonymous tuples and ufixedNxM in the contract! macro (#345), and 0.9.0 is not yet verified against algod 5.0 and Falcon accounts.

Duplication. I’ve read both. algokit-core is deliberately FFI-shaped, with interfaces that are “purely functional without any state owned by Rust”, sitting at 0.0.1 and unpublished on crates[.]io. It exists to carry Algorand out of Rust into other languages. xarmian/algod-rust is a node reimplementation, not a client SDK. So there isn’t a second Rust SDK on the table.

Discord. You’re right, and there’s no spin available. I don’t monitor that channel and that’s on me. Where I have been responsive is GitHub: 21 issues opened from outside the project, all closed, 15 of them within a month. I’ll start watching Discord regardless of how this goes.

Contributions. 307 of the 673 commits on main are mine (46%); by git blame over the hand-written Rust, 65%. The important part: I’m asking for the hours I contributed, not for the project. The 320 hours are derived from my commits only. Nobody else’s work is inside that number. If a major contributor wants to make their own claim, I’d support it. The project is open source with contributing guidelines; nobody contributed under an expectation of payment, myself included. This is retroactive, not owed.

One more correction while I’m here: my “About the team” section says I’ve maintained algonaut since 2019. My first commit is 4 January 2021, and someone else started the project in September 2019. I’ll fix that on the proposal.

7

Duplication. I’ve read both. algokit-core is deliberately FFI-shaped, with interfaces that are “purely functional without any state owned by Rust”, sitting at 0.0.1 and unpublished on crates[.]io. It exists to carry Algorand out of Rust into other languages. xarmian/algod-rust is a node reimplementation, not a client SDK. So there isn’t a second Rust SDK on the table.

Thanks for clarifying :slight_smile:

Rust’s share. I’d argue the causation runs the other way. Rust is the most-used language across the blockchain ecosystem at large, and it has led Stack Overflow’s most-admired ranking for close to a decade.

Isn’t this primarily due to Solana? Do any other blockchains also use Rust.

Would I recommend it over the Python or TypeScript SDKs? For a greenfield dapp, no: use TypeScript or Python. They have Foundation engineers and AlgoKit behind them, and I’d be doing a new developer a disservice by saying otherwise. If you’re already in Rust, writing a node, an enclave, a wasm32 client or an HSM-backed signer, then algonaut is the only thing you can cargo add

Appreciate your honesty here.

as of 0.9 it generates a typed client from an ARC-56 app spec.

Awesome, and the clients are usable?

Discord. You’re right, and there’s no spin available. I don’t monitor that channel and that’s on me.

Yes I agree.

I’m asking for the hours I contributed, not for the project.

I’m aware, I still feel that hours spent doesn’t translate directly to value for the community. I’m not saying this is your situation, but note that in the grand scheme of proposals, non-technical people can take days, weeks or longer zombie-prompting their way to a working version of something, which pulls a lot from existing source code — it doesn’t necessarily mean that something has value out of thin air. This is especially true for technical people who can create large projects at an even faster pace. That’s why I think it’s incredibly important that the feature contributions made by you are laid out plainly.

Note: Someone or something flagged you, reach out in the discord to regain access to the forums

9

Isn’t this primarily due to Solana? Do any other blockchains also use Rust.

Rust usage is widespread across the Blockchain industry, I prompted Claude with: What blockchain projects have nodes implemented in Rust? List only the major ones. for an up to date list.

Reply

Layer 1s written primarily in Rust

  • Solana: the main validator client (Agave, formerly the Solana Labs client) is Rust. Firedancer is the notable exception, written in C.
  • Polkadot / Substrate: the Polkadot SDK is Rust, so every Substrate-based chain inherits a Rust node (Kusama, Moonbeam, Astar, Acala, and dozens more).
  • NEAR: nearcore.
  • Aptos and Sui: both descend from Meta’s Diem codebase; node and Move VM are Rust.
  • Internet Computer (DFINITY): the replica is Rust.
  • Hyperliquid: HyperBFT and the node stack.
  • Namada and Penumbra: privacy chains, both Rust, with CometBFT for consensus.

Ethereum clients

  • Reth (Paradigm): execution client, now widely used and the base for several L2 nodes.
  • Lighthouse (Sigma Prime): consensus client.

L2s and rollup infrastructure

  • zkSync Era: the sequencer/server stack is Rust.
  • Starknet: Pathfinder full node, Madara sequencer, and the blockifier execution engine.
  • Espresso, Sovereign SDK, MegaETH (reth-based): Rust.
  • zk provers (RISC Zero, SP1) are Rust even where the chain itself isn’t.

Rust reimplementations of non-Rust chains

A growing category: alternative clients for existing networks, written to improve client diversity.

  • Zebra: Zcash (original zcashd is C++).
  • Forest: Filecoin (Lotus is Go).
  • Amaru: Cardano (original stack is Haskell).
  • Bitcoin has no production-grade Rust full node, though rust-bitcoin and LDK (Lightning) are heavily used libraries.

Hybrid cases worth knowing

Cosmos chains are Go, but CosmWasm contracts are Rust. MultiversX runs a Go node with a Rust contract framework. Mina is mostly OCaml with a Rust proof system.

Awesome, and the clients are usable?

Yes, of course. Please give them a try, the links are in my first reply above.

10

I’m in the Algorand ecosystem since the beginning and, to be fair, @gedl algonaut SDK was the first Rust SDK for Algorand and one of the very first unofficial SDKs developed solely by the community (as in, without any support from Algorand Inc. / Technologies / Foundation). It carried on the work inspired by mraof (which was unmaintained). So the question about the “duplication” should be directed to those who create a Rust SDK after, not first.

11

looks like when AF pays someone to do something that project usually dies.. Are you planning on adding Algorand 2.0 features like assets? · Issue #1 · mraof/rust-algorand-sdk · GitHub

i wonder what happens when AF goes bancrupt, who will manage the python and typescript libraries

12

The original Rust SDK was good till it was . For new SDK I personally would like to see the research basis behind it on current work and also new required SDK features based on TS SDK which is the main SDK.

I dont see that research and compatibility matrix anywhere in your repos. May be im wrong because i just took a quick look.
Also @scholtz please keep the conversation professional here and avoid any side trackings.
And Please kindly guide me to those parts of your SDK and also if possible guide me to some comparison script , automated test or proof or something that verifies or guarantees this works and is secure ideally identical to our well known SDKs or not.
I humbly think before an SDK is funded it must be proven to be usable and correct and secure.

13

as was mentioned here before, I do not develop rust SDK. My dotnet algo sdk is fully compatible with the algod 5.0.0 including native support of the post quantum accounts which I basically did for free and perhaps in the future will request again the retro grant for the dotnet sdk.

rewriting the algod to rust is out of scope anything in this proposal so i will not comment on it here

I will keep conversation as fact check as possible. My point was just that the person was paid to do some job, algorand picked him to do it, and he left right after the money was gone. The same happened in the dotnet where Frank had some direct paid deal with AF, and he left right after the contract was gone. If Algorand would pick someone with the interest to support this, perhaps today algorand would be promoting that it has the official dotnet and rust sdks. The fact is that the AF has algos to sell to fund its openrations only until 2030, so the risk that AF will go bancrupt is real, and it should start moving and promoting the algorand as a community not a blockchain managed by single CEO

14

Thank you for continuing this development, much needed to have a complete and issuless Rust SDK. Will you kindly continue to maintain it as well?

15

Hi @emg110 ! Thank you for your messages. There was no compatibility matrix in the repo and I just took the time to add one in the README under Compatibility.

Taking your points in turn.

A comparison against a known SDK. The matrix puts algonaut 0.9 next to js-algorand-sdk v3.7.0 surface by surface (clients, transaction types, signing, atomic groups and ABI, tooling).

An automated check that it behaves like the other SDKs. Algorand already has one: algorand/algorand-sdk-testing, the Gherkin suite that gates the Python, Java, Go and JavaScript SDKs. algonaut runs it against a live algod, indexer and kmd harness directly in CI. You can find a recent successful in the Actions tab.

The gaps. algod 5.0 and post-quantum is the big one: my pinned OpenAPI specs predate it, so Falcon-1024, PQ accounts, the PQ mnemonic and resource access lists are all missing, and algosdk v3.7 has them.

Every excluded scenario is a named entry in tests/cucumber/main.rs with a written reason, so please check that rather than take it from me.

Will I keep maintaining it? Yes, I maintained this through 0.5 to 0.9 with nobody paying for it, all of which predates this proposal. What funding that work would buy is bandwidth for algod 5.0 and post-quantum, which is where the gap actually is.

16

Thank you very much! Absolutely a big yes from me! We need this SDK very much!
Everyone: This SDK is required and used for many ground works in Agentic Algorand! Vote yes please!

17

An easy yes for me, same as it was for .net sdk some time back. Perhaps it’s not being used by hundreds of developers, but imo, if someone prefers to use rust as their goto language, this might be a deciding factor between that person/team building on algo or picking the next blockchain with faster to-market time due to better tooling.

As a retroactive ask, this proposal more than delivers on the retroactive part and has had its time to be tested in production - which is the main aim of retroactive aspect in the first place.

18

Update: Proposal submitted for voting

Thanks to everyone who took part in the discussion over the past few weeks. The minimum discussion period has now elapsed, and I’ve submitted the proposal to the voting phase on the xGov platform.

xGovs can now cast their votes at: https://xgov.algorand.co/proposal/3685107518. If you have any final questions, I’m happy to answer them here.

19

@simonb perfectly said what I was thinking as I read through this thread … better than I possibly could have.