This article is primarily aimed at developers or anyone writing an extension that would like to follow Rehive best practises.
For an account to be considered a tracking account it should follow the standard outlined below:
Core characteristics
It is never directly credited or debited by an admin or any other service logic besides the logic used to keep it up to date with the external account it represents.
It should not be included in the total user balance of the company
The balance of a tracking account should never be used for any real logic relying on balance checks.
A process should be in place to debit or credit the account on Rehive whenever a debit or credit is detected on the external account.
These accounts should be permissioned so that only specific admin accounts can view the balance.
Metadata
Most tracking account transactions will contain varying metadata fields to account for differing ledgers but all of them should contain the following fields:
External_id: Any unique identifier on the external ledger for the transactions (payment reference, crypto hash etc)
Created: Unix timestamp of the time it was created on the external ledger
Naming
The tracking account should clearly be prefixed with “tracking_” followed by an identifier for the external ledger and external account is tracking. Example for tracking a warm storage account on Stellar we would: “tracking_stellarmainnet_warmstorage_1”. The service responsible for the account should store the reference and the exact identifier (in this example the Stellar address) to act as the middleman between both ledgers.
Auto recon - Optional
For the majority of tracking accounts the codebase should have access to a read view of the external account. It can therefore auto recon the account to make no transactions are missing on Rehive. Initially the tracking account should be double checked once per-day and any missing transactions added.