[ANN] ⚙ Finalis Core | Testnet-3 live: Utxo/ Time Lock/ Long Lock.

[reikagi]

🎉 BIG WIN: `pow` Branch Is Production-Ready 🎉

After extended multi-node testing, the pow branch is now validated and ready for mainnet merge.

Included in This Update

• ✅ Validator onboarding: ONBOARDING status + PoW admission gating
• ✅ Consensus hardening: strict ingress epoch validation
• ✅ P2P improvements: 8-peer target + SEEDS.json discovery
• ✅ DB compatibility: backward-compatible replay path

Test Outcomes

• ✅ 4+ hours stable 2-node consensus
• ✅ 1,767+ blocks finalized consistently
• ✅ 0 validation failures, 0 DB errors
• ✅ Nodes converged on identical finalized hash

Reset Instructions (Linux) Need do all nodes

Code:

sudo systemctl stop finalis finalis-explorer
rm -rf ~/.finalis-core
git clone https://github.com/FinalisCore/finalis-core.git
cd finalis-core
cmake -S . -B build -G Ninja && cmake --build build -j
RESET_CHAIN_DATA=1 NODE_ROLE=joiner ./scripts/start.sh

You Can Now

• Mine mini-coins
• Stake or bond your amount

Minimum Hardware

• RAM: 1 GB
• CPU: Low-end CPU is sufficient

Windows Nodes 
Download: https://github.com/FinalisCore/finalis-core/releases/tag/v1.0.0

[unnamed0simple]

Discord invite link
Invite Invalid
This invite may be expired, or you might not have permission to join.

[reikagi]

Discord invite link
Invite Invalid
This invite may be expired, or you might not have permission to join.

Solved.  THANK.  After run Node, send FLS address.
Quick status update for operators and community. https://github.com/FinalisCore/finalis-core

Latest fixes

• Fixed wallet UTXO fallback selection to enforce canonical finalized state only (prevents stale/non-canonical input edge cases).
• Stabilized lightserver live RPC integration testing by pinning height/hash from one snapshot (CI race removed).
• Fixed Windows packaging/startup to use packaged mainnet genesis consistently (Linux/Windows behavior aligned).

Coin issuance & PoW

• Finalis does not use classic BTC-style miner-led emission.
• Ticket PoW is a bounded secondary mechanism (participation/ranking pressure), not sole finality authority.
• Issuance is deterministic and distributed through epoch settlement to eligible participants/validators.

Monetary economics (live model)

• Hard-cap target: 7,000,000 FLS
• Emission schedule: height-based, deterministic
• During emission: 10% protocol reserve, 90% settlement rewards
• If onboarding recipients exist: 3% of settlement rewards is carved into onboarding rewards
• After emission cap: new issuance = 0; fee settlement continues by epoch logic

Validator onboarding lifecycle

Code:

ONBOARDING -> PENDING -> ACTIVE

ONBOARDING does not auto-activate by waiting; bonded validator join is required.

Linux CLI commands (copy/paste)

Code:

# 1) Check current validator/operator status
./build/finalis-cli validator status \
  --db ~/.finalis/mainnet \
  --file ~/.finalis/mainnet/keystore/validator.json

# 2) Submit bonded validator join (registration)
./build/finalis-cli validator-register \
  --rpc http://127.0.0.1:19444/rpc \
  --db ~/.finalis/mainnet \
  --file ~/.finalis/mainnet/keystore/validator.json

# 3) Monitor onboarding progress
watch -n 20 './build/linux-release/finalis-cli validator-register-status --rpc http://127.0.0.1:19444/rpc --db ~/.finalis/mainnet --file ~/.finalis/mainnet/keystore/validator.json'

Operator note
If a node stalls at low height with settlement commitment mismatch on Windows, do a full chain DB reset (keep validator key) and restart with current packaged genesis. https://github.com/FinalisCore/finalis-core

[ckoozzzu]

Hi ,

I’ve spent some time running the node and wanted to share direct, technical feedback.

At the moment, peer connectivity is extremely limited — I’m consistently seeing only ~3 peers. There’s no apparent mechanism for automatic peer discovery within the network, which makes bootstrapping fragile and heavily dependent on manual configuration.

A more critical issue: when running two node instances on another machine, the behavior becomes unstable. As soon as the second instance begins syncing with peers, the first one stops progressing entirely. This suggests resource contention, networking conflicts, or flaws in how peer sessions / state are managed across instances.

It’s possible the setup behaves differently under Windows or with specific configurations, but in its current state, the codebase published on GitHub is not robust enough for reliable multi-instance or even consistent single-instance operation without manual intervention.

Calling this a “mainnet” feels overstated. From an operational and network-distribution standpoint, this is much closer to a testnet. As it stands, it looks like block production could realistically be handled by just 1–2 participants, which raises concerns about decentralization and network resilience.

My verdict: the project has potential, but it requires further development, stabilization, and likely a relaunch once the core networking and synchronization issues are properly addressed and the codebase reaches a production-ready state.

Happy to provide more logs or help test fixes if needed.

[BoozyTalking]

Windows node sync stuck at height 343. How to fix it? Deleteting database directory not helps.

[iaxtabaxta@gmail.com]

I have two nodes: 
1. Ubuntu 24 on a VPS — works well. 
2. Windows at home — not fully synchronized. After wiping the database, it synchronized up to height 1000+, but not completely. 

Maybe the issue is related to the IP type: the VPS uses a static IP, while my home connection has a dynamic IP. Could it be that synchronization works with a static IP but not with a dynamic one?

[bogdan198]

Hi ,

I’ve spent some time running the node and wanted to share direct, technical feedback.

At the moment, peer connectivity is extremely limited — I’m consistently seeing only ~3 peers. There’s no apparent mechanism for automatic peer discovery within the network, which makes bootstrapping fragile and heavily dependent on manual configuration.

A more critical issue: when running two node instances on another machine, the behavior becomes unstable. As soon as the second instance begins syncing with peers, the first one stops progressing entirely. This suggests resource contention, networking conflicts, or flaws in how peer sessions / state are managed across instances.

It’s possible the setup behaves differently under Windows or with specific configurations, but in its current state, the codebase published on GitHub is not robust enough for reliable multi-instance or even consistent single-instance operation without manual intervention.

Calling this a “mainnet” feels overstated. From an operational and network-distribution standpoint, this is much closer to a testnet. As it stands, it looks like block production could realistically be handled by just 1–2 participants, which raises concerns about decentralization and network resilience.

My verdict: the project has potential, but it requires further development, stabilization, and likely a relaunch once the core networking and synchronization issues are properly addressed and the codebase reaches a production-ready state.

Happy to provide more logs or help test fixes if needed.

I totally agree with your points. The network is super raw and unstable right now — calling it a mainnet is a stretch; it’s an early testnet at best.

reikagi , you should probably drop the "mainnet" label and run an incentivized testnet first to iron out all the bugs and glitches. Only once you’re 100% sure everything is solid should you go live with the mainnet. As it stands, this project won't fly. Nobody wants to use a buggy network that barely functions — it can’t even sync without hanging. Give it some thought.

[BoozyTalking]

This is even not a testnet - node not working at all - crashing whenever it decide to crash without any error message and not starting anymore while you not delete blockchain data directory.

[reikagi]

Thank you all for the honest, technical feedback.  I take it seriously.

You’re right about the current weak points: peer discovery is limited, multi-instance sync stability needs work, and NAT/dynamic IP support is not yet where it needs to be.  These are now my top priorities.

Current approach:
- Keep the network active so operators can continue testing under real-world conditions.,
- Run this as a hardening phase while we resolve stability and networking issues.,

Work in progress:
- Peer discovery and peer-count stability,
- Multi-instance sync/liveness fixes,
- NAT/dynamic IP connectivity improvements,
- Expanded validator/operator testing,
- Validator registration and reliability,
- New diagnostic command: finalis-cli sync_doctor [--db <dir>] [--tail <n>] [--json],
- New fast-sync command (details coming in the next update),

If you can share logs and repro steps (version/commit, config, OS, hardware, peer count, and exact sequence), that will help me fix issues faster.  Thanks again for pushing this forward with me.  I recommend everyone to rebuild:
1.

Code:

sudo systemctl stop fianlis fianlis-explorer

2.

Code:

git pull origin main

3.

Code:

cmake -S . -B build -G Ninja && cmake --build build

4.

Code:

sudo systemctl restart fianlis finalis-explorer

[reikagi]

Please update to the latest `finalis-node`/`finalis-cli` binaries now.  This release fixes multiple sync/restart failure modes that caused nodes to stall, restart from old heights, or fail startup replay.

**What was fixed**
1. Startup frontier self-repair was hardened:
- automatic frontier tail rollback now has adaptive cap fallback (`percent-of-tip` bounded by absolute max),
- repair trigger expanded to cover missing-lane-record replay failures,
- better startup diagnostics (`startup-frontier-tail-repair ...` with effective cap/reason).

2. Finalized ingress tip consistency during replay/apply:
- fixed repeated failures like `set-finalized-ingress-tip-failed`,
- added safe rewind path for finalized ingress tip when persisted state is ahead of contiguous replay,
- improved rejection detail logging (`frontier-block-reject ... detail=...`).

3. Sync certificate-path hardening:
- tightened certified transition handling for sync heights,
- improved sync-request lifecycle behavior to avoid stale request state,
- hardened serving/acceptance path around certified finalized transitions.

4. Startup race and buffering behavior:
- reduced early `node-not-running` rejects for startup transition flow,
- improved defer/buffer handling while node is entering running state.

5. Operator runtime defaults and launch stability:
- fixed `start.sh`/service command generation issue that could produce systemd `203/EXEC`,
- network defaults updated for resilience:
  - DNS seed discovery enabled (no forced `--no-dns-seeds`),
  - outbound peer target raised (default `8`) for better peer redundancy,
  - bootstrap mode now also keeps outbound peers.

**Why this matters**
- Fewer manual interventions for corrupted frontier tails.
- Better recovery from partial/inconsistent finalized ingress state.
- Lower probability of sync deadlock from weak/static peer topology.
- More deterministic startup/sync behavior after restart.

**Operator action**
1. Stop node service.
2. Deploy new binaries.
3. Restart with updated `scripts/start.sh`
4. Verify:
- no repeating `load_state failed`,
- no repeating `frontier-block-reject ... set-finalized-ingress-tip-failed`,
- peers establish and remain connected,
- `sync_doctor` no longer reports persistent `next_height_data_missing` due to peer starvation.

Live code on GitHub: https://github.com/FinalisCore/finalis-core The Windows release is not stable yet.  I’m currently working on Windows, but I want to finish Linux first.  If anyone is willing and has experience with Windows installers, it would be very helpful to support me.  Also, if you find something you don’t like, you can report it here or on GitHub issues.

[reikagi]

Today’s sync/finality hotfixes (please update from `main`): https://github.com/FinalisCore/finalis-core

1. Startup resume hardening
- Added rollback-floor safety so startup repair/checkpoint resume cannot rewind below trusted finalized floor.
- Added checkpoint resume guards and explicit failure reasons for unsafe resume paths.

2. Checkpointed startup correctness
- Fixed finalized-link hash continuity on checkpoint resume (`frontier_finality_link_hash` usage).
- Rebuilt lane roots from ingress certificates during checkpoint resume (instead of trusting stale lane-state only), with strict invariant checks.

3. Sync serving tightened (certified-only)
- `GET_TRANSITION` / `GET_TRANSITION_BY_HEIGHT` now serve only certified transitions.
- Added strict missing-cert / cert-mismatch refusal paths and logs.

4. Operator visibility added
- New counters surfaced in logs/doctor:
  - `served_transition_missing_certificate`
  - `served_transition_certificate_mismatch`

5. Sync diagnostics improved
- Added explicit sync receive/drop traces:
  - `sync-recv-next-height`
  - `sync-recv-drop` reasons
- Added `cert_height` to `send-frontier-by-height` logs for easier cross-node correlation.

6. Peer/rate-limit stability fixes for bootstrap sync
- Prevented bootstrap/static peers from being effectively deadlocked by stale ban gates.
- Bounded per-sweep `GET_TRANSITION_BY_HEIGHT` request burst per peer.
- Bypassed generic msg-rate throttling for inbound `TRANSITION` during catch-up backlog to prevent silent next-height starvation.
- Added explicit logging when inbound messages are rate-limited.

Please pull latest `main`, rebuild, and restart nodes.

https://github.com/FinalisCore/finalis-core
Fix & tested

• Diagnosed and fixed the sync-loss false positive: `TRANSITION` messages were being dropped too early by an over-broad `duplicate-accepted` short-circuit.
• Added targeted observability in the receive pipeline:
• - - peer pre-dispatch transition RX logging
• - - node entry `sync-recv-entry`
• - - explicit `sync-recv-drop` reasons (`decode-failed`, `frontier-parse-failed`, `duplicate-accepted`, `not-accepted` with path/height/cert context).
• Implemented the **duplicate-accepted horizon fix**:
• - - only drop duplicate payloads below `finalized_height + 1`
• - - bypass duplicate short-circuit at/above sync horizon and continue normal acceptance.
• Rebuilt `finalis-node` and `finalis-cli`; validated behavior live.
• Proved transport path is healthy and message ingress works end-to-end.
• Confirmed node can now catch up fully
• Net result: joiner sync progressed to tip on latest main-branch binary, with no active certificate/missing-next-height stall condition.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Everyone please update to latest `main` now.

Code:

cd ~/finalis-core
git pull origin main

sudo systemctl stop finalis finalis-explorer

cmake -S . -B build -G Ninja
cmake --build build

RESET_CHAIN_DATA=1 ./scripts/start.sh

.This includes the sync receive-path fixes and latest diagnostics; it is the required baseline for stable catch-up  Code lives: https://github.com/FinalisCore/finalis-core


How sync.. Node Fast: [step by step commands]

1.  

Code:

cd finalis-core

2.

Code:

git pull origin main

and

Code:

cmake -S . -B build -G Ninja && cmake --build build

3.

Code:

sudo systemctl stop finalis finalis-explorer

<-- use if not first time
4.

Code:

sudo systemctl reset-failed finalis

<-- use if not first time
5.

Code:

pgrep -af finalis-node || true

<-- use if not first time
6.

Code:

build/finalis-cli repair_state --db ~/.finalis/mainnet --force

7.

Code:

build/finalis-cli fast_sync --db ~/.finalis/mainnet --snapshot ./snapshot.bin --force

8.

Code:

./scripts/start.sh

or

Code:

sudo systemctl restart finalis finalis-explorer

note: Speed ​​depends on the iron content.

[reikagi]

🚀 Finalis Android Wallet APK is now available for testing!

Kotlin lovers & Android devs — we need your feedback and contributions!

Download v0.0.16 here:
https://github.com/FinalisCore/finalis-mobile/releases/tag/v.0.0.16

Test it, break it, suggest improvements.

[reikagi]

What We Fixed

1. Startup repair and observability

• Fixed repeated startup/init failures around finalized committee checkpoint recomputation.
• Added high-signal diagnostics for frontier settlement mismatch so one reject line shows exact actual vs expected commitments and replay inputs.

2. Deterministic canonicalization

• Patched canonical settlement derivation so validators converge on the same settlement outputs/commitment.
• Removed the `frontier-settlement-commitment-mismatch` divergence that blocked finalization.

3. Liveness behavior at round 0

• Added round-0 grace/deadline handling to prevent premature timeout fallback immediately after round-state reset/finalized advance.
• Reduced unnecessary round churn and improved proposal/vote progression stability.

4. Validator endpoint persistence

• Added `validators-addrman.dat` loader/persister (safe format, strict parse, self-endpoint filtering).
• Updated policy to persist active-validator endpoints and refresh periodically by finalized height.

5. Runtime disagreement telemetry tightening

• Refined `peer_height_disagreement`/observed height sampling to prioritize better peer subsets (validator-fresh first, then near-tip peers).
• Reduced noisy stale-peer impact on readiness signals.

6. CLI diagnostics update

• Extended `finalis-cli print_logs` to show `validators-addrman.dat` path and entry totals/tail for operational debugging.

This is an important consensus/liveness + diagnostics upgrade, so all validators should move to the new main branch.

[iaxtabaxta@gmail.com]

Why can’t finality be reached simply by achieving a quorum, without mandating a fixed block time—such as exactly 3 minutes? For instance, if a quorum is reached, the block could be approved—whether that takes 3 minutes, 1 minute, or 0.45 minutes. Wouldn't this increase speed?

[reikagi]

Why can’t finality be reached simply by achieving a quorum, without mandating a fixed block time—such as exactly 3 minutes? [...] Wouldn't this increase speed?

Good question.  Finality already works the way you describe: a block is final the moment the quorum (more than two-thirds of the committee) has precommitted, which takes seconds, not minutes.  There is no waiting period after the votes.

The 3 minutes is something else: the minimum gap before the next block may be proposed.  The protocol itself can run much faster (my test networks run several blocks per second).  I pace it on purpose, for four reasons:

• Time-based rules need a predictable block rate. Emission is defined per block (175,200 blocks per year, a 12-year schedule), the validator warm-up is 100 blocks (~5 hours) and committees rotate every 32-block epoch.  If blocks came "as fast as the quorum agrees", all of these would speed up or slow down with network conditions.
  
• Committee selection needs wall-clock time. Operators mine a small proof-of-work ticket for each epoch, and half of the interval is reserved as the ticket window.  Very short blocks would make that a race won by the fastest hardware.
  
• Without a minimum gap you get a stream of empty blocks. With no rule, validators on a fast network would finalize blocks continuously, even with no transactions, each one carrying a finality certificate.  That grows the chain and the light-client work for nothing, and I want a node to run on a Raspberry Pi with 1 GB of RAM.
  
• Room for slower validators. A gap that is generous compared with the voting time keeps validators on home connections from missing rounds and being suspended.
  

That said, you have a fair point about latency: a transaction currently waits for the next block, so up to ~3 minutes plus a few seconds.  The interval is a network parameter, not a law of the protocol, and the mainnet genesis is not frozen yet.  Shortening it (for example to 30-60 seconds), or proposing early when transactions are waiting and only pacing empty blocks, are both options I'm weighing before mainnet.  If you have a use case where 3 minutes hurts, I'd like to hear it.
Validator bonds now come from a faucet bot: type /faucet address:tsc1… in #faucet.  Testnet coins only come from block rewards (no premine, even on testnet), so bonds go out in order as the network earns them.  The first one is due around Oct 26, 04:00 UTC.  The bot shows your place and an ETA and pings you when your bond arrives.  Your node can run as a plain node meanwhile.

[reikagi]

Finalis Core
Final means final. Private by default. A wallet that checks instead of trusts.

Public testnet-3 is live, and I am looking for node operators and validators.

GitHub  |  Run a node  |  Live explorer  |  Whitepaper  |  Website  |  Discord

Status

• Mainnet: not launched. There is no mainnet coin, no sale and nothing to buy. Anyone offering FLS today is not me.
  
• testnet-3: live since 24 October 2026, 17:00 UTC. Same rules as mainnet, its own identity, and its coins have no value. It replaced testnet-1 after I moved the leader VRF to the RFC 9381 standard (see below).
  
• Code: open source, MIT license. Release v2.1.0: Linux packages (x86_64 and ARM64), a Docker image, and a Windows installer.
  

testnet-3 currently runs on one validator, mine, so every block depends on a single machine. Four independent validators is the first size that survives one going down. That is what I am asking for help with.


What is Finalis?

Finalis is a UTXO blockchain written from scratch in C++20. It is not a fork of Bitcoin, Ethereum or Cosmos. Three things set it apart:

1. Final means final.
A block is final once more than two-thirds of the validator committee has signed it, in two phases (prevote, then precommit). There is no fork choice and no reorgs, and nobody waits for "6 confirmations". A node only ever builds on the next height after the last final block:

Code:

state(h+1) = Apply(finalized_block(h+1), state(h))

For wallets, explorers and exchanges this means one simple rule: broadcast is submission, finalization is settlement. Target block time is 3 minutes.

2. Confidential transactions from genesis.
Amounts in confidential-to-confidential transfers are hidden with Pedersen commitments and Bulletproof range proofs (secp256k1-zkp). Outputs go to unlinkable one-time keys. This is part of the base layer from block 0, not an add-on.
To be clear about what stays public: shield and unshield amounts can be computed, the fee is public, and the transaction graph is visible. Details are in the confidential UTXO spec, section 3.3.

3. Your wallet checks, it does not trust.
The wallet starts from the genesis compiled into it, follows each committee handoff, and checks its balance against the validators' signatures. A server cannot invent coins for you, and one honest server is enough to expose a coin another server hides. See LIGHT_CLIENT.md.

Everything else is also derived deterministically from finalized history: committee selection, validator lifecycle, checkpoints and rewards. Every honest node computes the same result with no off-chain coordination.


Run a node (about 5 minutes)

You need Linux on x86_64 or ARM64 (a small VPS, Oracle Ampere, Raspberry Pi 4/5 are all fine), 1 CPU core, 1 GB RAM and about 10 GB of disk.

Option A: prebuilt package (Ubuntu 24.04+, Debian 13+, Fedora 40+, Arch)

Code:

curl -fsSL https://raw.githubusercontent.com/FinalisCore/finalis-core/main/scripts/install.sh | bash

It verifies the download's checksum and runs the node as a systemd service under its own user. Please read the script first; that is a good habit with any curl-to-bash.

Option B: Docker (any Linux)

Code:

docker run -d --name finalis --restart on-failure:5 \
  -p 19540:19540 -p 127.0.0.1:19544:19544 \
  -v finalis-data:/var/lib/finalis \
  ghcr.io/finaliscore/finalis-core:latest

Option C: build from source, or the Windows installer from the releases page.

Then open TCP port 19540 so other nodes can connect to you.
Full guide, including how to check you are on the right chain: testnet/JOIN.md


Become a validator

• Your node creates a testnet validator key on first start.
• Post your tsc1… address in Discord and I will send you the bond in testnet FLS, for free.
  
• Register with one command: finalis-cli --testnet validator-register
  
• After a 100-block warm-up (about 5 hours) you join the signing committee at the next epoch boundary (every 32 blocks).

The required bond shrinks as the validator set grows, so early validators need more testnet FLS, and I cover it. Validators that miss too many blocks are suspended, so use a machine that stays on. Validator bonds now come from a faucet bot: type /faucet address:tsc1… in #faucet.  Testnet coins only come from block rewards (no premine, even on testnet), so bonds go out in order as the network earns them.  The first one is due around Oct 26, 04:00 UTC.  The bot shows your place and an ETA and pings you when your bond arrives.  Your node can run as a plain node meanwhile.


Economics (mainnet parameters)

• No premine. All 7,000,000 FLS are emitted through block rewards.
  
• Hard cap: 7,000,000 FLS. Zero issuance after the cap.
  
• Emitted over 12 years, with issuance falling 20% each year.
• 10% of issuance accrues to a protocol reserve. The reserve is protocol state, not a wallet anyone controls.
• 3% of validator settlement rewards go to an onboarding bucket for new participants.
• After the cap, validators are paid from pooled fees, with deterministic reserve support.
• Target block time: 3 minutes (175,200 blocks per year).

Full details: ECONOMICS.md


Built to be checked

• TLA+ models of two-phase finality and checkpoint availability, model-checked in CI, including deliberately broken variants that must fail.
  
• Continuous fuzzing of consensus messages, P2P framing, sync, the sparse Merkle tree and confidential transactions.
  
• Nightly chaos runs with crashing and Byzantine validators, plus an adversarial protocol simulator.
  
• Standard VRF: leader randomness uses RFC 9381 ECVRF-EDWARDS25519-SHA512-TAI, checked against the RFC's published test vectors at every node start. Fuzzing found that my earlier custom VRF depended on the libsodium build; I fixed it at the root and restarted the testnet rather than ship it.
  
• Claims I want broken: docs/REVIEWING.md lists my safety, liveness and privacy claims, each with its spec section and code.
  

Mainnet is not launched, so a finding can still change the protocol itself. Please report vulnerabilities privately as described in SECURITY.md.


Programs

• finalis-node: full node, consensus and finalized execution
  
• finalis-lightserver: finalized-state JSON-RPC, with proofs clients can verify
  
• finalis-explorer: block explorer and a versioned partner API for exchanges
  
• finalis-wallet: Qt desktop wallet (transparent and confidential)
  
• finalis-cli: wallet, validator registration and diagnostics
  
• finalis-mobile: Android wallet (testnet)
  

Lightserver RPC methods include get_status, get_tx_status, get_tx, get_settlement, get_utxos, get_history_page, validate_address, broadcast_tx, and the light-client proofs get_committee_handoffs, get_utxo_proofs. Exchange integration guide: EXCHANGE_INTEGRATION.md


Roadmap to mainnet

• Grow testnet-3 to 4, then 10 or more independent validators.
• Independent review of the consensus safety rules and the confidential transaction cryptography.
• Genesis validator ceremony, then mainnet launch. The mainnet genesis will be committed to the repository so anyone can reproduce it (ceremony).
  

Questions, bug reports and criticism are welcome, here or on Discord.

github.com/FinalisCore/finalis-core

Finalis-core update: time locks, a new economic model, and testnet-3

Time-locked transactions (McFly)

- You can send a transaction that is sealed until a chosen future block height.  Validators sign each height once it is final, and those signatures open the transaction.  Nobody can read it or run it early, including the sender's counterparty.
- Built on BLS12-381 (blst) and signature-based witness encryption, with a proof that each sealed transaction is well-formed.
- Long locks open with the committee named when the transaction was included, so they work across validator-set changes.
- Sealed data reveals: publish data that stays hidden until a set height (for example sealed bids).
- Each time lock posts a 0.1 FLS bond, refunded when it opens validly and forfeited if the sealed body is invalid.  Fees scale with size.
- A validator that signs a height before it is final gets slashed.
- Wallet and "finalis-cli timed_send" support time-locked sends, cancelling them, and reading sealed data.

Height-locked outputs

- Coins that only become spendable at a set block height (vesting), with an inheritance form: the owner can spend at any time, and an heir can also spend from the unlock height on.
- Available from finalis-cli lock_send and the wallet's "Height-locked" send mode.

Economics (supply stays fixed at 7,000,000 FLS)

- 30% of block emission goes to a protocol reserve.  After emission ends, the reserve pays out 5% of its balance a year, so it never runs dry.
- Fees are pooled per epoch: half goes to that epoch's validators and half returns to the reserve.  Slashed bonds also return to the reserve instead of being destroyed.
- The base fee is zero when the network is quiet and rises with load.  Slashes and time-lock bodies are exempt.
- The minimum validator bond is 150 FLS at launch.  It grows slowly with the number of validators and the supply, and the amount you bond when you join is all you ever need.

Validators and launch model

- Genesis version 2: every validator, including the genesis ones, has a BLS time-signature key with a proof of possession.
- One bootstrap validator.  Everyone else joins by bonding faucet coins: no ceremony and no reserved slots.  Mainnet will launch the same way.
- The faucet gives out its first 128 bond grants, one per Discord account and address.

Security and robustness

- Transparent signatures now cover the value and script of every output being spent.
- Finalization is reported only after it is durably on disk, and storage failures are handled more strictly.
- This round's red-team findings are fixed, there are new fuzz targets for the time-lock decoders and sync, and the sanitizer and fuzz CI is green.

Tooling

- The CLI can read wallet passphrases from an environment variable, a file, or a prompt.
- The explorer and lightserver can take the client IP from a header such as CF-Connecting-IP when they run behind a proxy.
- Windows HTTPS now uses the system certificate store.

Running a testnet-2 node? Delete ~/.finalis/testnet (keep keystore/ to reuse your validator key), install the new release, and follow testnet/JOIN.md.

Email: reikagitakashi@gmail.com

[reikagi]

Finalis Core
Final means final. Private by default. A wallet that checks instead of trusts.

Public testnet-3 is live, and I am looking for node operators and validators.

GitHub  |  Run a node  |  Live explorer  |  Whitepaper  |  Website  |  Discord

Status

• Mainnet: not launched. There is no mainnet coin, no sale and nothing to buy. Anyone offering FLS today is not me.
  
• testnet-3: live since 24 October 2026, 17:00 UTC. Same rules as mainnet, its own identity, and its coins have no value. It replaced testnet-1 after I moved the leader VRF to the RFC 9381 standard (see below).
  
• Code: open source, MIT license. Release v2.1.0: Linux packages (x86_64 and ARM64), a Docker image, and a Windows installer.
  

testnet-3 currently runs on one validator, mine, so every block depends on a single machine. Four independent validators is the first size that survives one going down. That is what I am asking for help with.


What is Finalis?

Finalis is a UTXO blockchain written from scratch in C++20. It is not a fork of Bitcoin, Ethereum or Cosmos. Three things set it apart:

1. Final means final.
A block is final once more than two-thirds of the validator committee has signed it, in two phases (prevote, then precommit). There is no fork choice and no reorgs, and nobody waits for "6 confirmations". A node only ever builds on the next height after the last final block:

Code:

state(h+1) = Apply(finalized_block(h+1), state(h))

For wallets, explorers and exchanges this means one simple rule: broadcast is submission, finalization is settlement. Target block time is 3 minutes.

2. Confidential transactions from genesis.
Amounts in confidential-to-confidential transfers are hidden with Pedersen commitments and Bulletproof range proofs (secp256k1-zkp). Outputs go to unlinkable one-time keys. This is part of the base layer from block 0, not an add-on.
To be clear about what stays public: shield and unshield amounts can be computed, the fee is public, and the transaction graph is visible. Details are in the confidential UTXO spec, section 3.3.

3. Your wallet checks, it does not trust.
The wallet starts from the genesis compiled into it, follows each committee handoff, and checks its balance against the validators' signatures. A server cannot invent coins for you, and one honest server is enough to expose a coin another server hides. See LIGHT_CLIENT.md.

Everything else is also derived deterministically from finalized history: committee selection, validator lifecycle, checkpoints and rewards. Every honest node computes the same result with no off-chain coordination.


Run a node (about 5 minutes)

You need Linux on x86_64 or ARM64 (a small VPS, Oracle Ampere, Raspberry Pi 4/5 are all fine), 1 CPU core, 1 GB RAM and about 10 GB of disk.

Option A: prebuilt package (Ubuntu 24.04+, Debian 13+, Fedora 40+, Arch)

Code:

curl -fsSL https://raw.githubusercontent.com/FinalisCore/finalis-core/main/scripts/install.sh | bash

It verifies the download's checksum and runs the node as a systemd service under its own user. Please read the script first; that is a good habit with any curl-to-bash.

Option B: Docker (any Linux)

Code:

docker run -d --name finalis --restart on-failure:5 \
  -p 19540:19540 -p 127.0.0.1:19544:19544 \
  -v finalis-data:/var/lib/finalis \
  ghcr.io/finaliscore/finalis-core:latest

Option C: build from source, or the Windows installer from the releases page.

Then open TCP port 19540 so other nodes can connect to you.
Full guide, including how to check you are on the right chain: testnet/JOIN.md


Become a validator

• Your node creates a testnet validator key on first start.
• Post your tsc1… address in Discord and I will send you the bond in testnet FLS, for free.
  
• Register with one command: finalis-cli --testnet validator-register
  
• After a 100-block warm-up (about 5 hours) you join the signing committee at the next epoch boundary (every 32 blocks).

The required bond shrinks as the validator set grows, so early validators need more testnet FLS, and I cover it. Validators that miss too many blocks are suspended, so use a machine that stays on. Validator bonds now come from a faucet bot: type /faucet address:tsc1… in #faucet.  Testnet coins only come from block rewards (no premine, even on testnet), so bonds go out in order as the network earns them.  The first one is due around Oct 26, 04:00 UTC.  The bot shows your place and an ETA and pings you when your bond arrives.  Your node can run as a plain node meanwhile.


Economics (mainnet parameters)

• No premine. All 7,000,000 FLS are emitted through block rewards.
  
• Hard cap: 7,000,000 FLS. Zero issuance after the cap.
  
• Emitted over 12 years, with issuance falling 20% each year.
• 10% of issuance accrues to a protocol reserve. The reserve is protocol state, not a wallet anyone controls.
• 3% of validator settlement rewards go to an onboarding bucket for new participants.
• After the cap, validators are paid from pooled fees, with deterministic reserve support.
• Target block time: 3 minutes (175,200 blocks per year).

Full details: ECONOMICS.md


Built to be checked

• TLA+ models of two-phase finality and checkpoint availability, model-checked in CI, including deliberately broken variants that must fail.
  
• Continuous fuzzing of consensus messages, P2P framing, sync, the sparse Merkle tree and confidential transactions.
  
• Nightly chaos runs with crashing and Byzantine validators, plus an adversarial protocol simulator.
  
• Standard VRF: leader randomness uses RFC 9381 ECVRF-EDWARDS25519-SHA512-TAI, checked against the RFC's published test vectors at every node start. Fuzzing found that my earlier custom VRF depended on the libsodium build; I fixed it at the root and restarted the testnet rather than ship it.
  
• Claims I want broken: docs/REVIEWING.md lists my safety, liveness and privacy claims, each with its spec section and code.
  

Mainnet is not launched, so a finding can still change the protocol itself. Please report vulnerabilities privately as described in SECURITY.md.


Programs

• finalis-node: full node, consensus and finalized execution
  
• finalis-lightserver: finalized-state JSON-RPC, with proofs clients can verify
  
• finalis-explorer: block explorer and a versioned partner API for exchanges
  
• finalis-wallet: Qt desktop wallet (transparent and confidential)
  
• finalis-cli: wallet, validator registration and diagnostics
  
• finalis-mobile: Android wallet (testnet)
  

Lightserver RPC methods include get_status, get_tx_status, get_tx, get_settlement, get_utxos, get_history_page, validate_address, broadcast_tx, and the light-client proofs get_committee_handoffs, get_utxo_proofs. Exchange integration guide: EXCHANGE_INTEGRATION.md


Roadmap to mainnet

• Grow testnet-3 to 4, then 10 or more independent validators.
• Independent review of the consensus safety rules and the confidential transaction cryptography.

Questions, bug reports and criticism are welcome, here or on Discord.

github.com/FinalisCore/finalis-core

v2.2.2 is out, and I need every validator to update.  It fixes the slow blocks.  Validators behind a home router couldn't propose, so their turns timed out.  Nodes now relay proposals.  My two servers are updated, but the blocks only speed up once the affected validators update too.

Update the same way you installed:
- Docker: docker pull ghcr.io/finaliscore/finalis-core:latest, then recreate the container.  Keep your data volume.
- install.sh: re-run it.
- Built from source: rebuild from tag v2.2.2. Don't switch to the release tarball, because it can use an older RocksDB than your data.

After restarting, check that your node stays up, shows finalis-node/2.2.2, and keeps following new blocks.  One restart per validator, and please don't all restart at the same moment.

If anything fails, post your last 50 log lines in #bug-reports (Discord) or Here.  Windows installer coming shortly.

During my own upgrade, one of my servers went down for about 14 minutes.  The chain kept finalizing, so it's fine, but it's why I'm asking you to check.
Email: reikagitakashi@gmail.com

[reikagi]

Running a Finalis node at home (dynamic IP, home router, CGNAT)

A few people have asked me whether they can run a node or a validator from home, on an ordinary router with an IP address that changes.  Short answer: yes.  Here is how it works and where things stand right now.

Your IP is not your identity

The chain knows a validator by its key, not by its IP.  Your bond, your votes and your rewards are tied to the key, so when your ISP hands you a new address nothing changes on-chain.  The node also only needs outbound connections to do its job.

Two kinds of home connection

• Normal home router (the default in start.sh, PUBLIC_NODE=1): the node asks your router to open its P2P port through UPnP or NAT-PMP.  Every two minutes it asks a STUN server for its public address, so after an IP change it starts advertising the new one, and other nodes can connect to you again.
• Behind your ISP's shared NAT (CGNAT), or with UPnP switched off (PUBLIC_NODE=0): the node runs outbound-only.  It connects to the seeds, syncs, votes and, as a validator, proposes blocks through its peers.  This is not theory: on the current testnet three validators behind NAT are proposing blocks.

What happens when the IP changes

Your open connections drop, and the node reconnects to the seeds on its own.  Peers that still remember your old address try it once, fail and move on.  That does no harm.

One bug I found and fixed today

In the outbound-only case there was a real problem.  The lightserver that runs inside the node passes your transactions to the node over a local connection, and an outbound-only node wasn't listening for it.  So sending from the wallet or the CLI, and registering as a validator, failed on such nodes.  I found it while testing, wrote a test that reproduces it, and fixed it: the node now opens a listener on 127.0.0.1 only, so it is still not reachable from the outside.

The fix will be in the next release.  Until then, if you run with PUBLIC_NODE=0 you can still sync and validate, but for sends and registration please use the public HTTPS endpoint for now.

What I have not tested yet

I want to be straight about this.  I have not watched a real IP change on a real home router mid-run.  The reconnect behaviour above comes from the code and from my chaos tests, which cut connections between nodes but don't change their addresses.  I also don't have a number yet for how long the reconnect takes.  I plan to add a test where a node loses all its connections and has to find the seed again within a time limit.  If you run a node at home and your IP changes, I'd be glad to see your logs.

Questions and reports are welcome in this thread or Discord
Web: https://finalis-core.github.io/finalis-web/
Email:: reikagitakashi@gmail.com

[reikagi]

Finalis Core v2.2.10 is out — please update.

What I fixed:

- Home nodes behind NAT can send again.  Nodes that run outbound-only (no public port) with the built-in lightserver rejected every payment with "connect relay peer failed".  They now relay through a local loopback listener. I also tested a home IP change with a simulated router: the node reconnects by itself.
- Busy-node rejects are now retryable. "timed verify rate limited", "timed pool full" and "no canonical state" used to come back as tx_invalid, which told wallets not to retry.  They now return relay_unavailable, so wallets retry.
- Explorer: the participant count no longer counts the sender twice, and /api/tx now shows the transaction's timestamp.
- Quieter logs: per-message and per-height logs are off by default (set FINALIS_LOG_TRACE=1 to turn them back on).
- CLI: connection errors now name the target and the reason.
- Plus a thread-safety fix in the peer handshake and several test fixes.

No chain reset, no config changes. Your chain data and keys are kept.

How to update:

- Installed with install.sh: run the same command again: curl -fsSL https://raw.githubusercontent.com/FinalisCore/finalis-core/main/scripts/install.sh | bash
- Docker: docker pull ghcr.io/finaliscore/finalis-core:2.2.10 then recreate your container with the new image.
- From source: git fetch --tags && git checkout v2.2.10 rebuild, restart your service.

Stopping takes about a minute. Please update one at a time if you run several nodes. Check with finalis-node --version OR /build/finalis-node --version (should say 2.2.10).

WEB: finaliscore.org P.S. A validator in our network just independently acquired and contributed the domain http://finaliscore.org to the project.  ​This is proof of how organic, permissionless infrastructure growth works. FinalisCore belongs to everyone building it—anyone can contribute, optimize, or support the ecosystem at any level.  Huge thanks for setting a great precedent for future contributors.

Email: reikagitakashi@gmail.com