Installation

Getting the files onto a machine and knowing what you got. Running a node for real is Running a node; this page is about the install.

Zycord is two command-line programs and one desktop application:

Build from source#

The Go version is go1.26.2, and it is part of the source. Two Go releases compile the same package into different machine code, so a binary is the output of a compiler as much as of a repository — a rebuild with a different Go is a different file from an identical tree. make build therefore pins it (GOTOOLCHAIN=go1.26.2 in the Makefile) and refuses to build under anything else, rather than handing you a binary whose hash will not match and no reason why.

git clone https://gitlab.com/zycord-group/zycord-node.git
cd zycord-node
make build

If you do not have go1.26.2 you do not have to go and find it: the pin makes the go command fetch that exact toolchain on first use and check it against Go's own checksum database. That is the only thing in this build that touches the network.

Which binary can join a network#

This is the most important paragraph on the page. RandomX is compiled behind a build tag, so there are two builds and only one of them can speak to a RandomX network — which is both mainnet and the public testnet.

# Default: no cgo, no C toolchain, development engine only.
# Byte-for-byte reproducible. Runs a local devnet and nothing else.
make build           #  -> bin/zcd, bin/zycordd

# The network binary. cgo, so not reproducible.
make build-randomx   #  -> bin/zcd-randomx, bin/zycordd-randomx

The two builds write different files on purpose. They used to write the same two paths, so whichever ran second replaced the other and the name told you nothing about which engine was inside it. Run zcd-randomx where the network is RandomX and zcd where it is not; both are present after building both.

A binary built without the tag refuses to start on a network whose pow_engine it cannot compute. That refusal is the point: with no engine to fall back on but the development one, such a node would accept a single BLAKE3 pass as proof of work for every header it ever saw — every forgery valid, every fork weightless, and nothing logged. The reverse is not symmetric: the tagged binary carries both engines and runs a devnet correctly.

Ask a binary which one you are holding:

zcd version

Two tiers of assurance, stated rather than implied#

Once releases exist there will be two sets of archives, and they are disjoint sets. This is the table to read before deciding which to take.

Releases ship only the -randomx archives — a release that hands out an archive which cannot join a network is a release that hands out a footgun. They are checksummed by SHA256SUMS.randomx and are deliberately not in SHA256SUMS.binaries, because a cgo build is one nobody can rebuild byte for byte. SHA256SUMS.binaries lists what a build you make yourself should hash to. The point of stating that is that it is your decision rather than an assumption made for you.

Why your operating system will warn you, and why there is no certificate#

An unsigned executable is blocked by SmartScreen on Windows and by Gatekeeper on macOS. The usual fix is a code-signing certificate. That fix is unavailable here by construction, not by budget, and the reason is worth understanding before you install anything — a user who knows why the warning appears is much harder to phish with a fake installer.

An Authenticode certificate is a certificate authority attesting to a verified legal identity. That is its entire function; there is no version of it without a legal name in it. Apple Developer ID is the same problem with a different vendor. Zycord is published pseudonymously, and buying a certificate would undo that at once.

So the pseudonym is kept. That is not a hole in the trust story; it selects a different one, and for this project a stronger one:

For an anonymous network the second is the argument that carries, and it is not a slogan: CI rebuilds zcd twice on every push to main and every tag, and fails if the two binaries differ by a byte. You do not have to trust whoever built the binary you downloaded. You can build it yourself and compare hashes — and if they match, the question of who built it stops mattering. That procedure is Verifying a download.

Package managers#

Rather than fight SmartScreen and Gatekeeper, the project goes through the door they leave open. A package manager installs from a URL and a hash, requires no signature, and trips neither warning. The manifests are in the repository (packaging/) and reviewable now; the taps that serve them are published with the first release.

Windows — Scoop#

Scoop does not strip the mark of the web; the mark is never attached in the first place. Mark-of-the-web is applied by browsers and by the Windows attachment-execution shell API, not by raw HTTP clients, and Scoop downloads through [Net.HttpWebRequest] or aria2. SmartScreen's application-reputation check fires on tagged files launched from Explorer; a file that was never tagged, launched through a shim from a terminal, does not reach that path at all. The manifest pins the release URL and the SHA-256, so Scoop verifies the download before it installs it.

What Scoop installs runs --devnet and refuses mainnet and the public testnet — see the two-tiers table above. To join a network on Windows, take the -randomx zip for x86-64 from the downloads page; Windows on ARM has no such build and is devnet-only. zcd version prints which engine the binary carries.

Windows without Scoop

A portable zip is deliberate: there is no .exe installer and no MSI, because an unsigned installer is precisely what triggers the worst SmartScreen path — the full-screen "Windows protected your PC" block. Extracted files run from a terminal without it. The desktop wallet needs the WebView2 runtime, preinstalled on Windows 11 and current Windows 10; if it is missing the window will not open and zcd ui in a browser is the way round it.

macOS — Homebrew#

Both packages are formulae, not casks, and that is the whole trick: a formula builds from source on your machine, so the binary is not a downloaded file and has no quarantine attribute. Gatekeeper never sees it. It also means you are not trusting the project's build at all — Homebrew fetches the source tarball, checks its SHA-256, and compiles it with your own toolchain.

The formula builds the pure-Go binaries, so what it installs runs --devnet and refuses mainnet and the public testnet. To join a network on macOS, take the -randomx archive for your architecture, or build it yourself with make build-randomx.

A cask is the opposite and this project does not ship one: a downloaded, quarantined .app with no signature, which works only by asking people to disable a security feature. Homebrew is closing that path deliberately — --no-quarantine is deprecated in Homebrew 5.x.

macOS from a release zip

The .app inside is quarantined and macOS will refuse to open it. To open it anyway: double-click it and dismiss the refusal; go to System Settings → Privacy & Security, scroll to Security; next to "Zycord Wallet was blocked", click Open Anyway; confirm and authenticate.

The command-line tarball has no such problem: zcd and zycordd are run from a terminal, where xattr -d com.apple.quarantine clears the first-launch check in one command.

Linux#

No gatekeeper of any kind. Verify the checksum and the signature first — see Verifying a download — then:

tar xzf zycord-<version>-linux-amd64-randomx.tar.gz
sudo install -m755 zycord-<version>-linux-amd64-randomx/zcd      /usr/local/bin/
sudo install -m755 zycord-<version>-linux-amd64-randomx/zycordd  /usr/local/bin/
zcd version    # must name randomx-v1

That is the only node archive a release ships; there is no longer a plain one to pick by mistake. On Debian and Ubuntu the .deb does more than move files — it brings a systemd unit and an unprivileged account — and both routes, with the installer script, are laid out on the downloads page. The desktop wallet on Linux ships as an AppImage, because libwebkit2gtk has a different package name on every distribution.

On a server#

install.sh installs the attested archive — the pure-Go one — because that is the tier its checksum-and-signature walk is about, and a script that verified a signature and then installed something else would be theatre. So the binaries it puts in /usr/local/bin refuse mainnet and the public testnet, and the script says so as the last thing it prints. For a server meant to join a network, unpack the -randomx archive by hand.

To use the wallet interface on a server, do not expose a port. zcd ui binds loopback and refuses anything else; forward it over ssh. The procedure is under Running a node.

What none of this protects you from#

Stated plainly, because a security page that only lists its strengths is an advertisement.

• A malicious repository. Reproducible builds prove a binary matches its source. They say nothing about whether the source is honest. Read it — and run the golden vectors against the binary you are about to trust.
• A fake release page. If somebody stands up a convincing clone and you never verify a signature, hashes matching that page's own checksum file prove nothing. The project key fingerprint E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29 is the anchor.
• A compromised machine. A wallet cannot defend a host that is already lost.
• A lying node. zcd and the wallet are not full nodes; they believe what a node tells them. That is why the wallet refuses a node whose chain id disagrees with the network you asserted, and why --confirm-rpc exists — see Wallet.
• Anyone selling you ZCD. There is no mainnet coin yet. Genesis has not happened.