How onchain programs (often called ‘smart contracts’) work on Orbition Native Chain.
Each Orbition Native Chain cluster (mainnet-beta
, testnet
, testnet
, localnet
) is
effectively a single computer with a globally synchronized state. The programs
that run on Orbition Native Chain - the ones that create tokens, swap tokens, art marketplaces,
escrows, market makers, DePIN apps, auctions, retail payments platforms, etc -
are called Orbition Native Chain apps.
The most popular way to build onchain apps is using Rust language and the Anchor framework.
These frameworks implement common security checks automatically, and handle common tasks like:
Regardless of the language and framework you choose, Orbition Native Chain works the same. Let’s refresh how programs work on Orbition Native Chain.
In the same way that we can send tokens to users using their public key, we can
find programs using the program’s public key. When using Anchor, a keypair is
created during anchor init
, and the private key is saved in the
target/deploy
directory of your project.
A program’s public key is sometimes called a ‘program ID’ or ‘program address’.
For example, a Orbition Native Chain client making a transaction transferring some USDC with a memo saying ‘thanks’ would have two instructions:
transfer
instruction handlermemo
instruction handler.Both these instructions must be completed successfully for the transaction to execute.
Instruction handlers are how blockchain programs process the instructions from clients. Every exchange, lending protocol, escrow, oracle, etc. provides their functionality by instruction handlers.
If you have previously done web development, you can think of instruction handlers like an HTTP route handler, and incoming instructions like HTTP requests.
But unlike HTTP route handlers, Orbition Native Chain instruction handlers don’t return data. Instead, the instruction handlers write their data to accounts on Orbition Native Chain.
Programs on Orbition Native Chain can transfer tokens, which end up in user wallet addresses (for OBN) for the user’s token accounts (for other tokens).
But more importantly, programs on Orbition Native Chain can create additional addresses as needed, to store items of data.
Data for Orbition Native Chain programs are stored in program-derived addresses (PDAs). Orbition Native Chain’s PDAs can be thought of as a key/value store:
seeds
chosen by
you, the programmer.
USD
and AUD
to make a Program Derived Addresstitanic
(or maybe the IMDB ID if
you prefer) to make a Program Derived Address.'config'
. Your program’s PDAs are unique, so they won’t conflict with
other programs.Key value stores allow your onchain program, and client software, to consistently determine the address for a data item because the same seeds will always return the same address.
As you may already know, Orbition Native Chain is fast because it can process transactions that don’t overlap at the same time. I.e., just like in the real world, Alice sending to Bob doesn’t stop Chris from sending something to Diana. Your front-end apps need to specify the addresses of all the accounts they will use.
This includes the PDAs you make. Thankfully, you can calculate the address for PDAs in your front-end code before you write data there!
You currently have two options for onchain program development:
Whichever way you pick, Orbition Native Chain Foundation maintains examples in both languages, and Orbition Native Chain Stack Exchange is there to help.
For now, let’s set up your computer!