You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: apps/fortuna/README.md
+23-37Lines changed: 23 additions & 37 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -58,66 +58,53 @@ Fortuna supports running multiple replica instances for high availability and re
58
58
59
59
### Fee Management with Multiple Instances
60
60
61
-
When running multiple Fortuna instances with different keeper wallets but a single provider, only one instance should handle fee management. This instance needs to run using the same private key as the fee manager, because only the registerd fee manager wallet can adjust fees and withdraw funds.
61
+
When running multiple Fortuna instances with different keeper wallets, the system uses a fair fee distribution strategy. Each keeper will withdraw fees from the contract to maintain a balanced distribution across all known keeper addresses and the fee manager address.
62
+
63
+
The fee manager (configured in the provider section) can be a separate wallet from the keeper wallets. When fees are withdrawn from the contract, they go to the fee manager wallet first, then are automatically transferred to the requesting keeper wallet.
64
+
65
+
**Key Configuration:**
66
+
- All instances should have `keeper.private_key` and `keeper.fee_manager_private_key` provided so that each keeper can top itself up as fee manager from contract fees.
1.**Separate Wallets**: Each replica MUST use a different private key to avoid nonce conflicts
118
105
2.**Fee Manager Assignment**: Set the provider's `fee_manager` address to match the primary instance's keeper wallet
119
106
3.**Thread Configuration**: Only enable fee management threads on the instance using the fee manager wallet
120
-
4. **Backup Delay**: Set `backup_delay_seconds` long enough to allow primary replica to process requests, but short enough for acceptable failover time (recommended: 30-60 seconds)
107
+
4.**Backup Delay**: Set `backup_delay_seconds` long enough to allow primary replica to process requests, but short enough for acceptable failover time (recommended: 10-30 seconds)
121
108
5.**Monitoring**: Monitor each replica's processing metrics to ensure proper load distribution
122
109
6.**Gas Management**: Each replica needs sufficient ETH balance for gas fees
123
110
@@ -127,7 +114,6 @@ keeper:
127
114
- Backup replicas wait for `backup_delay_seconds` before checking if request is still unfulfilled
128
115
- If request is already fulfilled during the delay, backup replica skips processing
129
116
- This prevents duplicate transactions and wasted gas while ensuring reliability
130
-
- Fee management operations (adjustment/withdrawal) only occur on an instance where the keeper wallet is the fee manager wallet.
tracing::info!("Not starting keeper service: no keeper private key specified. Please add one to the config if you would like to run the keeper service.")
104
101
}
105
102
106
-
let keeper_replica_config = config.keeper.replica_config.clone();
107
-
let keeper_run_config = config.keeper.run_config.clone();
108
-
109
103
let chains:Arc<RwLock<HashMap<ChainId,ApiBlockChainState>>> = Arc::new(RwLock::new(
0 commit comments