ord
is an index, block explorer, and command-line wallet. It is experimental
software with no warranty. See LICENSE for more details.
Ordinal theory imbues satoshis with numismatic value, allowing them to be collected and traded as curios.
Ordinal numbers are serial numbers for satoshis, assigned in the order in which they are mined, and preserved across transactions.
See the docs for documentation and guides.
See the BIP for a technical description of the assignment and transfer algorithm.
See the project board for currently prioritized issues.
Join the Discord server to chat with fellow ordinal degenerates.
Ordinals is open-source and community funded. The current lead maintainer of
ord
is raphjaph. Raph's work on ord
is
entirely funded by donations. If you can, please consider donating!
The donation address is bc1qguzk63exy7h5uygg8m2tcenca094a8t464jfyvrmr0s6wkt74wls3zr5m3.
This address is 2 of 4 multisig wallet with keys held by raphjaph, erin, rodarmor, and ordinally.
Bitcoin received will go towards funding maintenance and development of ord
,
as well as hosting costs for ordinals.com.
Thank you for donating!
ord
relies on Bitcoin Core for private key management and transaction signing.
This has a number of implications that you must understand in order to use
ord
wallet commands safely:
-
Bitcoin Core is not aware of inscriptions and does not perform sat control. Using
bitcoin-cli
commands and RPC calls withord
wallets may lead to loss of inscriptions. -
ord wallet
commands automatically load theord
wallet given by the--name
option, which defaults to 'ord'. Keep in mind that after running anord wallet
command, anord
wallet may be loaded. -
Because
ord
has access to your Bitcoin Core wallets,ord
should not be used with wallets that contain a material amount of funds. Keep ordinal and cardinal wallets segregated.
Alpha ord
wallets are not compatible with wallets created by previous
versions of ord
. To migrate, use ord wallet send
from the old wallet to
send sats and inscriptions to addresses generated by the new wallet with ord wallet receive
.
ord
is written in Rust and can be built from
source. Pre-built binaries are available on the
releases page.
You can install the latest pre-built binary from the command line with:
curl --proto '=https' --tlsv1.2 -fsLS https://ordinals.com/install.sh | bash -s
Once ord
is installed, you should be able to run ord --version
on the
command line.
On Linux, ord
requires libssl-dev
when building from source.
On Debian-derived Linux distributions, including Ubuntu:
sudo apt-get install pkg-config libssl-dev build-essential
On Red Hat-derived Linux distributions:
yum install -y pkgconfig openssl-devel
yum groupinstall "Development Tools"
You'll also need Rust:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Clone the ord
repo:
git clone https://github.com/ordinals/ord.git
cd ord
To build a specific version of ord
, first checkout that version:
git checkout <VERSION>
And finally to actually build ord
:
cargo build --release
Once built, the ord
binary can be found at ./target/release/ord
.
ord
requires rustc
version 1.76.0 or later. Run rustc --version
to ensure
you have this version. Run rustup update
to get the latest stable release.
A Docker image can be built with:
docker build -t ordinals/ord .
ord
is available in Homebrew:
brew install ord
To build a .deb
package:
cargo install cargo-deb
cargo deb
If you wish to contribute there are a couple things that are helpful to know. We
put a lot of emphasis on proper testing in the code base, with three broad
categories of tests: unit, integration and fuzz. Unit tests can usually be found at
the bottom of a file in a mod block called tests
. If you add or modify a
function please also add a corresponding test. Integration tests try to test
end-to-end functionality by executing a subcommand of the binary. Those can be
found in the tests directory. We don't have a lot of fuzzing but the
basic structure of how we do it can be found in the fuzz directory.
We strongly recommend installing just to make running the tests easier. To run our CI test suite you would do:
just ci
This corresponds to the commands:
cargo fmt -- --check
cargo test --all
cargo test --all -- --ignored
Have a look at the justfile to see some more helpful recipes (commands). Here are a couple more good ones:
just fmt
just fuzz
just doc
just watch ltest --all
If the tests are failing or hanging, you might need to increase the maximum
number of open files by running ulimit -n 1024
in your shell before you run
the tests, or in your shell configuration.
We also try to follow a TDD (Test-Driven-Development) approach, which means we use tests as a way to get visibility into the code. Tests have to run fast for that reason so that the feedback loop between making a change, running the test and seeing the result is small. To facilitate that we created a mocked Bitcoin Core instance in test-bitcoincore-rpc.
ord
requires a synced bitcoind
node with -txindex
to build the index of
satoshi locations. ord
communicates with bitcoind
via RPC.
If bitcoind
is run locally by the same user, without additional
configuration, ord
should find it automatically by reading the .cookie
file
from bitcoind
's datadir, and connecting using the default RPC port.
If bitcoind
is not on mainnet, is not run by the same user, has a non-default
datadir, or a non-default port, you'll need to pass additional flags to ord
.
See ord --help
for details.
ord
makes RPC calls to bitcoind
, which usually requires a username and
password.
By default, ord
looks a username and password in the cookie file created by
bitcoind
.
The cookie file path can be configured using --cookie-file
:
ord --cookie-file /path/to/cookie/file server
Alternatively, ord
can be supplied with a username and password on the
command line:
ord --bitcoin-rpc-username foo --bitcoin-rpc-password bar server
Using environment variables:
export ORD_BITCOIN_RPC_USERNAME=foo
export ORD_BITCOIN_RPC_PASSWORD=bar
ord server
Or in the config file:
bitcoin_rpc_username: foo
bitcoin_rpc_password: bar
ord
uses env_logger. Set the
RUST_LOG
environment variable in order to turn on logging. For example, run
the server and show info
-level log messages and above:
$ RUST_LOG=info cargo run server
Release commit messages use the following template:
Release x.y.z
- Bump version: x.y.z β x.y.z
- Update changelog
- Update changelog contributor credits
- Update dependencies
To translate the docs we use mdBook i18n helper.
See mdbook-i18n-helpers usage guide for help.
Adding a new translations is somewhat involved, so feel free to start translation and open a pull request, even if your translation is incomplete.
Take a look at this commit for an example of adding a new translation. A maintainer will help you integrate it into our build system.
To start a new translation:
-
Install
mdbook
,mdbook-i18n-helpers
, andmdbook-linkcheck
:cargo install mdbook mdbook-i18n-helpers mdbook-linkcheck
-
Generate a new
pot
file namedmessages.pot
:MDBOOK_OUTPUT='{"xgettext": {"pot-file": "messages.pot"}}' mdbook build -d po
-
Run
msgmerge
onXX.po
whereXX
is the two-letter ISO-639 code for the language you are translating into. This will update thepo
file with the text of the most recent English version:msgmerge --update po/XX.po po/messages.pot
-
Untranslated sections are marked with
#, fuzzy
inXX.po
. Edit themsgstr
string with the translated text. -
Execute the
mdbook
command to rebuild the docs. For Chinese, whose two-letter ISO-639 code iszh
:mdbook build docs -d build MDBOOK_BOOK__LANGUAGE=zh mdbook build docs -d build/zh mv docs/build/zh/html docs/build/html/zh python3 -m http.server --directory docs/build/html --bind 127.0.0.1 8080
-
If everything looks good, commit
XX.po
and open a pull request on GitHub. Other changed files should be omitted from the pull request.