Skip to content

solana-labs/solana-program-library

master
Switch branches/tags
Code

Latest commit

* chore: Use GovernanceTokenConfig

* wip: add council_token_config to RealmConfigAccount

* chore: update comment

* wip: use GoverningTokenConfigArgs for community token config

* chore: Change Proxy token type to Dormant

* chore: Update comments

* chore: Use GoverningTokenConfigAccountArgs for instructions creators

* chore: Use default  GoverningTokenType

* chore: Make community_token_args optional

* chore: Make Clippy happy

* chore: Update comments

* chore: Always create RealmConfigAccount

* chore: Set CouncilTokenConfig when realm is created

* feat: Update RealmConfigArgs in SetRealmConfig

* chore: Make Clippy happy

* chore: Assert RealmConfigAccount PDA

* wip: Use default RealmConfigAccount if the account doesn't exist

* chore: Remove use_community_voter_weight_addin and use_max_community_voter_weight_addin from RealmConfig

* chore: code review cleanup

* wip: Use voter weight addin for Council

* feat: Use max_voter_weight_plugin for Council

* feat: Impl RevokeGoverningTokens instruction

* chore: Make Clippy happy

* feat: Enforce governing token withdraw and deposit rules

* feat: Support minting deposits

* feat: Do not enforce token source owner for deposit validation

* chore: test_deposit_community_tokens_using_mint

* chore: Remove not implemented comment

* fix: Fix progrma id for resolving realm config for chat

* chore: Update instructions comments

* feat: Do not allow community Liquid token change to Membership

* chore: test_set_realm_config_with_liquid_community_token_cannot_be_changed_to_memebership_error

* chore: test_set_realm_config_for_community_token

* chore: use GoverningTokenConfig for test args

* chore: Refactor SetRealmConfigArgs

* chore: Update RealmSetupArgs names

* chore: test_set_realm_config_for_council_token_config

* chore: Revoke council tokens tests

* chore: test_revoke_council_tokens_with_realm_authority_must_sign_error

* chore: test_revoke_council_tokens_with_invalid_realm_authority_error

* chore: test_revoke_council_tokens_with_invalid_token_holding_error

* chore: RevokeGoverningToken tests

* chore: Dormant and Membership tokens tests

* chore: Using council plugin tests

* chore: RealmConfigAccount validation tests

* chore: Update Dormant token type configs

* fix: Reset legacy fields

* chore: Use Default macro for derivable defaults

* Chore: use assert functions to validate spl-token account and mint

* chore: Update Membership tokens comments

* chore: Pass governing_token_config_args as reference

* chore: Use single statement to return InvalidRevokeAmount error

* chore: Make Clippy happy - add derived Eq

Co-authored-by: Jon Cinque
6dfc68d

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
ci
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Build status

Solana Program Library

The Solana Program Library (SPL) is a collection of on-chain programs targeting the Sealevel parallel runtime. These programs are tested against Solana's implementation of Sealevel, solana-runtime, and deployed to its mainnet. As others implement Sealevel, we will graciously accept patches to ensure the programs here are portable across all implementations.

Full documentation is available at https://spl.solana.com TypeDocs: https://solana-labs.github.io/solana-program-library/token/js/

Development

Environment Setup

  1. Install the latest Solana tools from from https://docs.solana.com/cli/install-solana-cli-tools.
  2. Install the latest Rust stable from https://rustup.rs/. If you already have Rust, run rustup update to get the latest version.
  3. Install the libudev development package for your distribution (libudev-dev on Debian-derived distros, libudev-devel on Redhat-derived).

Build

Build on-chain programs

# To build all on-chain programs
$ cargo build-sbf

# To build a specific on-chain program
$ cd <program_name>/program
$ cargo build-sbf

Build clients

# To build all clients
$ cargo build

# To build a specific client
$ cd <program_name>/cli
$ cargo build

Test

Unit tests contained within all projects can be run with:

$ cargo test      # <-- runs host-based tests
$ cargo test-sbf  # <-- runs BPF program tests

To run a specific program's tests, such as SPL Token:

$ cd token/program
$ cargo test      # <-- runs host-based tests
$ cargo test-sbf  # <-- runs BPF program tests

Integration testing may be performed via the per-project .js bindings. See the token program's js project for an example.

Common Issues

Solutions to a few issues you might run into are mentioned here.

  1. Failed to open: ../../deploy/spl_<program-name>.so

    Update your Rust and Cargo to the latest versions and re-run cargo build-sbf in the relevant <program-name> directory, or run it at the repository root to rebuild all on-chain programs.

  2. Error while loading shared libraries. (libssl.so.1.1)

    A working solution was mentioned here. Install libssl.

    wget http://nz2.archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1l-1ubuntu1.2_amd64.deb
    sudo dpkg -i libssl1.1_1.1.1l-1ubuntu1.2_amd64.deb
  3. CPU or Memory usage at 100%

    This is to be expected while building some of the programs in this library. The simplest solution is to add the --jobs 1 flag to the build commands to limit the number of parallel jobs to 1 and check if that fixes the issue. Although this will mean much longer build times.

Clippy

$ cargo clippy

Coverage

$ ./coverage.sh  # Help wanted! Coverage build currently fails on MacOS due to an XCode `grcov` mismatch...

MacOS

You may need to pin your grcov version, and then rustup with the apple-darwin nightly toolchain:

$ cargo install grcov --version 0.6.1
$ rustup toolchain install nightly-x86_64-apple-darwin

Release Process

SPL programs are currently tagged and released manually. Each program is versioned independently of the others, with all new development occurring on master. Once a program is tested and deemed ready for release:

Bump Version

  • Increment the version number in the program's Cargo.toml
  • Generate a new program ID and replace in <program>/program-id.md and <program>/src/lib.rs
  • Run cargo build-sbf <program> to update relevant C bindings. (Note the location of the generated spl_<program>.so for attaching to the Github release.)
  • Open a PR with these version changes and merge after passing CI.

Create Github tag

Program tags are of the form <program>-vX.Y.Z. Create the new tag at the version-bump commit and push to the solana-program-library repository, eg:

$ git tag token-v1.0.0 b24bfe7
$ git push upstream --tags

Publish Github release

  • Go to GitHub Releases UI
  • Click "Draft new release", and enter the new tag in the "Tag version" box.
  • Title the release "SPL vX.Y.Z", complete the description, and attach the spl_<program>.so binary
  • Click "Publish release"

Publish to Crates.io

Navigate to the program directory and run cargo package to test the build. Then run cargo publish.

Disclaimer

All claims, content, designs, algorithms, estimates, roadmaps, specifications, and performance measurements described in this project are done with the Solana Foundation's ("SF") best efforts. It is up to the reader to check and validate their accuracy and truthfulness. Furthermore nothing in this project constitutes a solicitation for investment.

Any content produced by SF or developer resources that SF provides, are for educational and inspiration purposes only. SF does not encourage, induce or sanction the deployment, integration or use of any such applications (including the code comprising the Solana blockchain protocol) in violation of applicable laws or regulations and hereby prohibits any such deployment, integration or use. This includes use of any such applications by the reader (a) in violation of export control or sanctions laws of the United States or any other applicable jurisdiction, (b) if the reader is located in or ordinarily resident in a country or territory subject to comprehensive sanctions administered by the U.S. Office of Foreign Assets Control (OFAC), or (c) if the reader is or is working on behalf of a Specially Designated National (SDN) or a person subject to similar blocking or denied party prohibitions.

The reader should be aware that U.S. export control and sanctions laws prohibit U.S. persons (and other persons that are subject to such laws) from transacting with persons in certain countries and territories or that are on the SDN list. As a project based primarily on open-source software, it is possible that such sanctioned persons may nevertheless bypass prohibitions, obtain the code comprising the Solana blockchain protocol (or other project code or applications) and deploy, integrate, or otherwise use it. Accordingly, there is a risk to individuals that other persons using the Solana blockchain protocol may be sanctioned persons and that transactions with such persons would be a violation of U.S. export controls and sanctions law. This risk applies to individuals, organizations, and other ecosystem participants that deploy, integrate, or use the Solana blockchain protocol code directly (e.g., as a node operator), and individuals that transact on the Solana blockchain through light clients, third party interfaces, and/or wallet software.