Purpose and philosophy

UXDProgram responsibility is to provide a secure framework where the UXD stablecoin lives on the Solana blockchain. This include setting up the stack (on chain accounts), parameterisation, swap between collateral and redeemable (UXD), insurance management, on chain accounting and rebalancing operations.

This is enabled through providing a permissionned API(authority is the DAO in our case), and a permissionless API for end users to access the service. The sources can be found here on GH.

The API is detailed in the Instruction section of this book, the permissionned ones are prefixed with a 🔐.

The Open Source Typescript client UXD-Client is the recommended way to interact with the program, although not required (raw IDL available). The sources can be found here on GH.

Technical choices

The program is written in Rust using the Anchor framework.

Code style wise, the focus is on variable naming, comprehensiveness and simplicity over elaborated patterns or conciseness. We have big screen these days, we can handle long explicit names, long list of files 💖.

The code is organised in the "JetProtocol" way, with an instruction and its IDL per file in the instructions folder.

The most idiomatic Anchor and rust code is preferred, latest versions of Anchor are used as they comes.

All code hitting production is audited by sec3.dev (previously Soteria).

Limited time to implement, infinite time to get rekt

You have limited time to code and maintain the contract, but once out there, there is a nearly infinite amount of time and people that will look for ways to abuse functionalities or exploit vulnerabilities.

This induce a very asymmetrical situation, although we have the initiative.

As such, the first thing to keep in mind when growing the codebase is to think about how much surface of attack, complexity, and composability risk are added, and to keep these as low as possible to keep the fight fair. If it's simple enough, having 10h or 1000h doesn't really make a difference into understanding the code and finding issues.

Another important point is that the code should be as independant as possible from other parties: no hardcoding, no assumptions about how other Solana Program work, only dynamic retrieval of other parameters, and no deported code (all logic we use that is not ours should be calculated on the service side not ours.

You want the code to be as straightforward as possible, so that anyone can get a feel about it quickly when it's open sourced, and also to onboard new hires comfortably.