Rust SDK for Synthetix v3

Username

50

Grant Description

Request for funding for one developer to create an SDK in Rust for the Synthetix v3 contracts, modelled on the already existing Python SDK repo.

Overview

Upon completion a github repo will have been created which houses a Rust transcription of the Python SDK which can be found at https://github.com/Synthetixio/python-sdk/tree/main. It will have, as much as is possible given the differences in language, feature parity with the existing version and have an equal level of documentation and code examples. Emphasis will be put upon making it as true a port as possible (function names, architecture, ect), and when finished the crate will be published to crates.io where it will be publicly accessible. Finally, a dedicated support group will be set up where any bugs/feature requests can be instantly seen and responded to.

Value to Synthetix

The primary value add is that it allows potential integrations whose codebases are written in Rust to start building upon the Synthetix protocol much faster than would otherwise be possible. Given that a Python version has already been created, one could say that there is a consensus on the value in having such a repository available, and porting it to other popular languages seems to be a logical next step.

Project Implementation Plan

At a high level, project implementation will be split into the following four phases:

1. Porting the code This phase will consist of initialising a github repo and populating it with all the desired functionality; as outlined above, this means transcribing the methods, classes and error handling from the Python version into its Rust equivalent.

2. Testing The next step would be to create a test suite that covers all possible edge cases and boundary conditions - some common errors to specifically look out for would be conflicting dependencies (i.e, will the code break if a new version of the ethers/alloy crate is released?) and unhelpful/obscure error handling.

3. Documentation Somewhat self-explanatory although its worth again noting that special attention will be given to being as clear and as similar to the Python version as possible.

4. Maintenance Window As there will of course be questions from integration partners and edge cases that weren't fully caught in the testing stage, one would suggest a 3-month period of maintenance wherein I'd be on-hand in both the Synthetix Discord and the dedicated support group to answer any queries/fix bugs/add additional features that may arise. It would be my estimation that 3 months is a long enough period of time to catch the majority of edge cases and handle most questions, as well as providing enough time for any other interested party to familiarise themselves with the code and documentation.

Additional Information

Unless directed otherwise, project development progress would be tracked through a public notion page. Re: Timelines I estimate the full project would be completed inside 4 weeks + maintenance window, broken down as follows: Stage 1: 2 Weeks Stage 2: 1 Week Stage 3: 1 Week Maintenance Window: 3 Months

Given that the required work will be greatly helped by having Troy's repo to work with as a template it's entirely possible that it ends up getting finished before the 1 month deadline, but we will add some buffer to account for any unforeseen errors/issues that might arise.

Funding Request

For the scope outlined above the following grant is requested: Month 1: 4000 SNX Maintenance Window: 750 SNX/month

I would suggest streaming payments via an on-chain protocol such as Sablier and controlling the steam via a multisig owned by the grants council as this allows the project to retain the right to cancel the stream at any time if the contract requirements are not met. The figures above are aggregate estimations from existing proposals on the SNX forums (specifically the Dune Dashboards and Integrator fee analysis proposals), as well as similar proposals from other forums (see: https://gov.gmx.io/t/open-grant-application-gmx-python-sdk/2653) and average salaries for Rust developers sourced from websites such as web3.career. Given that the grant would be distributed in a volatile asset across a prolonged period of time, some buffer has been added to the figure to account for the inventory risk (no offence, crypto is just volatile).

As a final note I would ask for feedback on the proposal from the grants council and wider community, both on the funding request figures and the proposed scope of work and implementation plan. I'll be reachable here as well as on Discord (50shadesofgwei) and Telegram (@JonathanFeasby).