Flare Entity and FSP Setup
This guide deploys the Flare Systems Protocol stack from flare-systems-deployment. It assumes the validator node is already running and its NodeID can be linked to the same Entity identity.
What the Stack Runs
COMPOSE_PROFILES=fsp,fast-updates starts the production FSP stack:
| Service | Protocol | Image tag checked |
|---|---|---|
c-chain-indexer-db | FSP storage | mysql:9.5.0 |
c-chain-indexer | FSP indexer | flare-system-c-chain-indexer:v1.1.2 |
system-client | FSP submissions / registration / finalization | flare-system-client:v1.0.12 |
ftso-client | FTSOv2 anchor feeds | ftso-scaling:v1.0.9 |
fdc-client | FDC voting data | fdc-client:v1.2.9 |
fast-updates | FTSOv2 block-latency feeds | fast-updates/go-client:v1.0.2 |
Step 1: Register FSP Addresses
Generate and secure five addresses:
| Role | Storage | Purpose |
|---|---|---|
Identity | Cold storage | Main Entity identity, proposals, node registration, key rotation |
Submit | Hot storage | submit1, submit2, submit3 transactions |
SubmitSignatures | Hot storage | submitSignatures transactions |
SigningPolicy | Hot storage | Reward epoch registration, signing policy, relay/finalization signing |
Delegation | Cold or controlled wallet | Receives WNat delegation and rewards, establishes vote power |
On mainnet, manually register roles through EntityManager using the propose-confirm flow:
| Role | Call from Identity | Confirm from proposed role address |
|---|---|---|
Submit | proposeSubmitAddress | confirmSubmitAddressRegistration |
SubmitSignatures | proposeSubmitSignaturesAddress | confirmSubmitSignaturesAddressRegistration |
SigningPolicy | proposeSigningPolicyAddress | confirmSigningPolicyAddressRegistration |
Delegation | proposeDelegationAddress | confirmDelegationAddressRegistration |
The automated registration script requires private keys in a JSON file and is only recommended by Flare for testnets. For mainnet, use manual contract calls or a carefully reviewed signing workflow.
Fund all five addresses with FLR for gas. The Delegation address also needs at least 150 WNat for vote weight recognition.
Step 2: Register Fast Updates Sortition Key
Generate a sortition key pair:
docker run --rm ghcr.io/flare-foundation/fast-updates/go-client:v1.0.2 keygen
Example output fields:
{
"PublicKeyX": "0x...",
"PublicKeyY": "0x...",
"PrivateKey": "0x..."
}
Generate the verification signature using the sortition private key and your Identity address:
docker run --rm ghcr.io/flare-foundation/fast-updates/go-client:v1.0.2 keygen \
--key 0x_SORTITION_PRIVATE_KEY \
--address 0x_IDENTITY_ADDRESS
Call EntityManager.registerPublicKey(bytes32 _part1, bytes32 _part2, bytes _verificationData) from the Identity address using PublicKeyX, PublicKeyY, and the generated signature.
Step 3: Create Fast Updates Hot Accounts
Generate at least three additional hot accounts for Fast Updates:
FAST_UPDATES_ACCOUNTS=0x_private_key_1,0x_private_key_2,0x_private_key_3
These accounts are not the same as the five FSP addresses. Fund each account with FLR for frequent Fast Updates gas costs.
Step 4: Prepare FTSO Feed Value Provider
Production operators must run their own robust Feed Value Provider. It must be reachable from the FSP containers and implement:
| Endpoint | Used by |
|---|---|
POST /feed-values | Fast Updates Client |
POST /feed-values/:votingRoundId | FTSO Scaling Client |
For integration testing only, the official example provider can run on 3101:
docker run --rm -it \
--publish "127.0.0.1:3101:3101" \
ghcr.io/flare-foundation/ftso-v2-example-value-provider
If the provider runs on the same host as Docker, use the host bridge address in .env, for example:
VALUE_PROVIDER_URL=http://172.17.0.1:3101
FAST_UPDATES_VALUE_PROVIDER_URL=$VALUE_PROVIDER_URL/feed-values/0
The example provider is not a mainnet-grade pricing system. Poor data quality or downtime can cause FTSO minimal-condition failures and lost rewards.
Step 5: Prepare FDC Verifier URLs
Complete FDC Suite Setup first, then collect verifier URLs and API keys. These become variables such as:
BTC_PAYMENT_URL=http://fdc-suite-internal:9801/verifyFDC
BTC_PAYMENT_API_KEY=...
FLR_EVMTRANSACTION_URL=http://fdc-suite-internal:9800/verifyFDC
FLR_EVMTRANSACTION_API_KEY=...
ETH_EVMTRANSACTION_URL=http://fdc-suite-internal:9800/verifyFDC
ETH_EVMTRANSACTION_API_KEY=...
Exact URLs depend on how you split FDC suite components. Keep verifier APIs on a private network and require VERIFIER_API_KEYS.
Step 6: Clone Flare Systems Deployment
sudo mkdir -p /data/flare
sudo chown -R $USER:$USER /data/flare
cd /data/flare
git clone https://github.com/flare-foundation/flare-systems-deployment.git
cd /data/flare/flare-systems-deployment
git checkout 0fa4ac7
Step 7: Configure .env
cp .env.example .env
chmod 600 .env
Minimum mainnet values:
COMPOSE_PROJECT_NAME=flare-systems-deployment
COMPOSE_PROFILES=fsp,fast-updates
NETWORK=flare
NODE_RPC_URL=http://YOUR_PRIVATE_FLARE_RPC:9650/ext/bc/C/rpc
NODE_API_KEY=
IDENTITY=0x_identity_address
SUBMIT_PK=0x_submit_private_key
SIGNATURES_PK=0x_submit_signatures_private_key
SIGNING_PK=0x_signing_policy_private_key
PROTOCOL_X_API_KEY_100=strong_ftso_client_api_key
VALUE_PROVIDER_URL=http://172.17.0.1:3101
FAST_UPDATES_ACCOUNTS=0x_private_key_1,0x_private_key_2,0x_private_key_3
FAST_UPDATES_SORTITION_PRIVATE_KEY=0x_sortition_private_key
FAST_UPDATES_VALUE_PROVIDER_URL=$VALUE_PROVIDER_URL/feed-values/0
PROTOCOL_X_API_KEY_200=strong_fdc_client_api_key
BTC_PAYMENT_URL=http://YOUR_FDC_VERIFIER/verifyFDC
BTC_PAYMENT_API_KEY=strong_verifier_key
# Add each FDC attestation URL/API key you support.
This .env contains hot private keys. Keep permissions at 600, restrict server access, never commit it, and rotate affected keys immediately if exposed.
Step 8: Generate Config and Start
cd /data/flare/flare-systems-deployment
./populate_config.sh
docker compose pull
docker compose up -d
Re-run ./populate_config.sh every time .env changes.
The C-Chain indexer template defaults to a large history window. Flare docs allow reducing the window, but warn not to go below 350,000 blocks or the FTSO client may fail.
Step 9: Verify Services
docker compose ps
docker compose logs -f system-client
docker compose logs -f c-chain-indexer
docker compose logs -f ftso-client
docker compose logs -f fdc-client
docker compose logs -f fast-updates
Healthy logs should eventually show voter registration and protocol submissions:
| Log pattern | Meaning |
|---|---|
RegisterVoter success | Entity registered for an upcoming reward epoch |
Submitter submit1 successfully sent tx | FSP submission path is working |
Submitter submitSignatures successfully sent tx | Signature submission path is working |
Relaying finished for protocol 100 with success | FTSOv2 finalization success |
Relaying finished for protocol 200 with success | FDC finalization success |
Minimal Conditions
FSP rewards depend on meeting all active minimal conditions:
| Protocol | Minimum condition |
|---|---|
| Staking | 80% uptime with at least 1M FLR self-bond; earning passes additionally requires 3M FLR active self-bond and 15M active stake |
| FTSO anchor feeds | Estimates within a 0.5% band around consensus median in 80% of voting rounds |
| FTSO Fast Updates | At least 80% of expected updates, except very low weight providers below 0.2% total active weight |
| FDC | Correct Merkle-root participation in 60% of voting rounds |
Check:
IDENTITY_ADDRESS="identity_without_0x"
curl "https://flare-systems-explorer-backend.flare.network/api/v0/entity?query=${IDENTITY_ADDRESS}" \
-H "Accept: application/json" | jq -r '.results[0].entityminimalconditions'
You can also use the Flare Systems Explorer.
Updates
cd /data/flare/flare-systems-deployment
git fetch --tags origin
git log --oneline -5 origin/main
docker compose pull
./populate_config.sh
docker compose up -d
Read upstream release notes and repository changelogs before changing commits or image tags.