A lightweight standard for non-fungible assets.
Warning
The asset program has not been formally audited – use in production at your own risk.
The main goal of asset is to provide an open-source, lightweight and composable non-fungible standard on Solana. This is achieved by:
- Using a single account to represent a digital asset.
- Storing as much or as little data on-chain using optional extensions.
- Efficient zero-copy de-/serialization to minimize compute units utilization.
- Full-featured standard, including royalty enforcement, delegates, lock/unlock, inscriptions and groups (collections).
- Rust and JavaScript client packages.
Majority of NFT standards on Solana are built on top of SPL Token, which is mainly a fungible token program. A non-fungible is created by adding restrictions to fungible mints – i.e., for a mint to be considered "non-fungible", it must have supply 1, decimals 0 and no mint authority. As a consequence, NFT standards carry "baggage" from the requirements of fungibles to represent non-fungibles. For example, while non-fungibles have a supply of 1 by definition, there is still a requirement for separate mint and token accounts. Requiring a separate mint and token accounts is wasteful and adds complexity (e.g., more accounts validation) to a standard. In most cases, the only information required from a non-fungible token account is the owner (holder) address, given that the amount is always expected to be 1. At the same time, a token account takes 165 bytes of storage. Additionally, SPL Token - even including Token Extensions (a.k.a., SPL Token 2022) - does not enforce constraints to define different token standards.
Since different token standards will usually be defined in separate programs, the end result is a bloated (multiple accounts) standard – e.g., mint, token and (potentially) metadata accounts, in addition to SPL Token and Metadata programs. For most operations, all 5 accounts would be needed to interact with a non-fungible – and there are standards that the number of accounts is even higher.
asset takes a different approach and re-imagines how non-fungibles are represented on Solana. In essense, a non-fungible asset is a unique slab of bytes on the blockchain identified by an address and it has an specific owner. When you transfer the "ownership" of this slab of bytes, you are changing the owner information of it. The contents of a non-fungible is as flexible as possible, given that they are "just" a slab of bytes – all data can be on-chain, or it can have "pointers" to external resources.
The packages below can be used to interact with asset program.
npm install @nifty-oss/assetcargo add nifty-assetTo build the programs from the root directory of the repository:
pnpm installto install the required libraries, then:
pnpm programs:buildThis will create program binaries at <ROOT>/programs/.bin.
The repository contains both Rust BPF and TypeScript test. These can be run from the root directory of the repository:
pnpm clients:rust:testfor Rust BPF tests, and:
pnpm clients:js:testfor TypeScript tests.
This project contains the following programs:
-
assetAssetGtQBTSgm5s91d1RAQod5JmaZiJDxqsgtqrZud73 -
bridgeBridgezKrNugsZwTcyAMYba643Z93RzC2yN1Y24LwAkm
You will need a Rust version compatible with BPF to compile the program, currently we recommend using Rust 1.68.0.
Each program in the project contains autogenerated Javascript and Rust clients:
Asset:
Bridge:
The project includes a Rust-based command-line interface:
Check out the Contributing Guide the learn more about how to contribute to this project.
Copyright (c) 2024 nifty-oss maintainers
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.