Pool Manager
- Introduction
- Fetch required data
- Fetching the data
- Building a Transaction Plan
- Executing a Transaction Plan
The pool manager has a very specific workflow that you must adopt when using it, it can be broken down in the following steps:
- Fetch inflation pool's data on voters, their balances, and the pool's balance
- Build a Transaction Plan
- Execute a Transaction Plan
Each step is described below.
There are currently two ways of acquiring the data needed to build a transaction plan:
- Retrieving it from https://fed.network/inflation/PUBLIC_ADDRESS
- Retrieving it from the database of a fully synced Horizon Node in your local network
In both cases the inflation pool's data is meant to follow this JSON structure:
{
"inflationdest" : "GCFXD4OBX4TZ5GGBWIXLIJHTU2Z6OWVPYYU44QSKCCU7P2RGFOOHTEST",
"entries" : [ {
"balance" : 241000855630,
"account" : "GDAYAP2TGOR7TH36QQNLBRCLI4K767BCUELUDYUJBFO4L4F3TW2ZLY23"
}, {
"balance" : 241000855630,
"account" : "GCY656DBMIZ4HVUUJHD6CDHWABZUB4DQ6I4LQI23LZ6HJGRAD4CQ5E3L"
}, {
"balance" : 241000855630,
"account" : "GACFVZE2XGMTNGG36FYITB7EQATVLG5BR5TS2UCQ5HDPGZCQKIZU4WJB"
}, {
"balance" : 241000855630,
"account" : "GAF2N6W2NGXV7VLBBYHDGI6RLEXSSBWMD5IA4RQQSZDDEVLAUDF5HRCT"
}, {
"balance" : 241000855630,
"account" : "GCYJSKHLOZDW2UABSZI4RKOAMQR6PLFNXRAIBJO5OD63PFBHVDVPKUEM"
}, {
"balance" : 241000855630,
"account" : "GBOQ2HJNW27SBMZ4EHBZK4ASRTMZY2SOJ26G6RIJLTK5BC3WY6DXO2ZE"
} ]
}
- Retrieve data from Fed.network (uses an http connection to retrieve the json)
- Retrieve data from Horizon Node (uses a direct database connection, requires editing settings)
- Refresh pool's balance (uses the stellar SDK currently selected network type [TEST/LIVE])
- Build transaction plan (will only work once data has been retrieved)
- Status box, green means you're on the TEST network, red means you're LIVE. You will see the sum total of your data here.
You will find the settings panel in the "File -> Settings" menu entry. The settings you can edit are the following:
- Stellar Network (TEST/LIVE): This will affect which network is used to execute the transactions.
- Inflation Pool Address: If you don't want to enter the pool address every time in the main window, this allows you to set a default value.
- Federation Network URL: in case it changes in the future, you can update it here.
- Memo Text: This is the memo that will be set on every transaction on your behalf.
- Fee: This is the network fee that Stellar requires for each operation, you cannot specify a value of less than 100 (hardcoded minimum at the time of writing). Knowing the fee is required to calculate proper payouts, since some accounts might have such a low balance that the operation minus the fee could end up being negative (you will be warned of such accounts).
- Horizon connections settings: Self explanatory if you know what you are doing. You must be able to reach the horizon database on your network. WARNING the password is saved in plain text in the .ini file within the
datafolder, your local database ports should NEVER be accessible from the internet anyway.
Once you've selected your target network (TEST/LIVE), enter the pool's public address in the main window's related field and either use the button to get the data from Fed.network or your custom Horizon Node (if your horizon node is configured on a different network than the one you want to operate, you will be warned).
If everything goes well, you should see this:
It's now time to push the big button and build a transaction plan!
The Transaction Plan serves as a snapshot point, once generated it will represent a plan of the amount you will pay to each voter, and who receives that money. This allows to recover from a partial execution if, for example, something as bad as losing internet connection happens while you're executing it. More on this later!
Here is an overview of the interface:
- Inflation amount: This field represents the amount of inflation you are paying, it's expressed in XLM and must be a decimal number, such as
123.0or123.23423. Several checks are in place to make sure you can't screw this up by mistake (such as specifying an amount that's above the current pool's balance, or simply inputting the wrong text). - Transaction builder: This is usually your second interaction in this window, once you've specified the inflation amount you'll want to build the transaction plan and check it's data (see #8 after you've built a plan)
- This is the signing key to execute the transactions, until you specify this you will not be able to execute.
- The execution button: will only proceed if you have built a valid plan and provided a signing key
- Force the current plan to be saved to the data folder (optional, the plan is automatically saved when you push the "EXECUTE TRANSACTIONS" button)
- Save the current contents of the rerouting list. Useful if you always have the same reroutes and don't want to input them every time.
- Save the exclusions list. Same functionality as the reroutes, if you have default exclusions you can permanently save them after you've made changes.
- Once you've built (or rebuilt) a plan, its overview will appear here, showing you the total amount that will be distributed after the fees. It's should match the inflation amount you specified minus the fees for every voter. The
executedtransactions count will only update when you come back here from execution.
The exclusions list is an important tool, it allows you to specify accounts that should be excluded from payment. This is useful when you need to feed back transaction results into the planner to recover from a partial execution run.
The transaction results file format that is saved at the end of each execution is already in the correct format that will be understood by the exclusions list, so you can simply copy and paste it in there
network
If you would rather edit an exclusions list manually you must follow this format:
{
// These nodes are all the exclusion list cares about.
// You can use a partial transaction result here to recover from a payment run that did not fully complete!
"entries": [
{
"destination": "GXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}
]
}
NOTE You can use C style comments in the json, it will not prevent parsing
The rerouting list allows you to reroute a voter's inflation to a different payment destination. Someone might ask you for example to count their votes, but pay their inflation to a different address. Whether you want to offer this service or not is up to you.
IMPORTANT NOTE The rerouting list is processed before exclusions, which means that the rerouted address, not the voter's balance address, is the one that must be added to the exclusions list
This is the format that the rerouting list understands:
{
// Rerouted entries will be processed before exclusions!
// If the rerouted destination is present in the exclusions list it will be excluded as expected
"entries": [
{
"account": "GXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"reroute": "GXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}
]
}
NOTE You can use C style comments in the json, it will not prevent parsing
So, you made it to the execution. Here you are just greeted with a friendly reminder that you should not attempt to forcibly interrupt the operation until it's completed, and given the last chance of going back to double check your transaction plan.
When you are ready, press start and you'll begin to see the progress of the operation.
Execution might take a while, sit back, relax, and follow the process. At the end of it you will see an important message:
The message tells you that it has saved the transaction results in a specific file. This is your operation report! It's good for archival purposes, but especially good in case the operations gets interrupted before being able to fully complete. This report file will be written even for partially executed transactions, and you can integrate its contents in the exclusions list to rebuild the transaction plan and continue from where it was interrupted.