Discussion of TigerBeetle Core Ledger Integration

[bushjames]

• @MichaelJBRichards mentions that we may still want to allow adopters to use MySQL database ledger version.
  • JB: The approach has been to replace the MySQL ledgers with TB ledgers and it doesnt make sense to maintain two core ledger implementations going forward.
  • MR: We say we are DB agnostic dont we?..
  • JB: This is not the reality; we are pretty well stuck with MySQL even though we use knex.
  • Discussion around acceptance criteria for TB integration.
    • All tools still have to work with the new ledger e.g. reporting, ops tools etc... no degradation of features or NFRs There must be a very solid upgrade mechanism / migration path.
  • Why do we need to be DB agnostic and not agnostic about anything else in the system?
  • What is the product requirement? Is there a strong ask from adopters for us to be DB agnostic?
  • Are folks worries about there not being a managed service for TB from the big providers.
  • PM asks if we should not release a TB moja until managed TB services are available in the market.
  • Should we ensure managed services are available for ALL our critical/core stack components?
  • MR mentions that the TB integration is involving rework of the chart of accounts; this could/may impact the existing ledgers.
  • JB raises that the engineering effort is larger to maintain two underlying ledger techs into the future. Unless there is a very strong requirement from the market we should aim to switch cleanly from mysql ledgers to TB.
  • MR suggests that this needs to go to the TGB as it is such a critical decision. Lets make a proposal and take it to them.
  • The group agrees that we will make a proposal to the TGB to make a clean swap from sql ledgers to TB and not maintain sql ledgers beyond a solid TB based moja release. Aim to take to TGB in July before next virtual convening so we can announce our position.

[bushjames]

Discussed at DA today. Update from evolution workstream:

MR reports that Chart of accounts changes are still being discussed.

Lewis Daly is making good progress on technical integration of TigerBeetle. Interfaces are defined to cleanly cut existing ledger functions and abstract so we will have two alternative "drop in" ledger implementations.

This also allows testing to prove both work to specifications; although, there are likely to be some functional differences between the two implementations.

Note that both ledgers implementations will need to support Settlement v3. Lewis will ensure this is the case for the TigerBeetle implementation. Some other resources will be needed to update the mysql ledgers to support Settlement v3.

Lewis will present his work at the DA for approval at an appropriate point in the near future.

[bushjames]

Meeting happened in London on 17th November 2025 including MA and WC from TGB, JB and LD (tigerbeetle) to discuss proposed tigerbeetle integration architecture and chart of accounts. The integration plan was presented by LD and approved by all present. Chart of accounts was discussed and no changes were requested. JB mentions that he expects design documentation to be presented to the DA in the coming weeks.

[bushjames]

@PaulGregoryBaker raises a point that recording liquidity in the switch ledger as a liability could cause confusion and is hard for lay-people to understand. In Paul B's experience no schemed hold liquidity funds in accounts they control, and thus liquidity is not a liability for the scheme operator.

@PaulMakinMojaloop agrees that it is possible/likely that liquidity funds will not be held in accounts that the scheme operator controls. Contractual obligations can allow DFSPs to hold their liquidity in their own accounts.

JB suggests taking this query to the TGB for further discussion before implementation of the CoA moves forward. JB will facilitate the conversation.

[bushjames]

SK requests that presentation of the design to the DA happen urgently. JB will follow up with LD to speed this process up.

[millerabel]

To clarify, the Chart of Accounts maintained by TigerBeetle is not the switch ledger. It does not reflect the business accounting of the switch company. It is a clearing ledger, recording only the assets and obligations of the participants, from the clearing system frame of reference. Our model follows double-entry accounting standards. Assets = Liabilities + 0 There is no equity, no income, and no expenses. However, all assets controlled by the clearing system and recorded in the clearing ledger must be reflected by liabilities in the clearing ledger. The Assets reflect the liquidity available to the switch to perform its programmed functions; the Liabilities represent claims on those assets by the participants. A participant can only act on its claims via API calls to Mojaloop. Actual funds are not held by the switch and funds are not transferred between institutions by Mojaloop—funds are on deposit in trust and transferred only by the trust institution via settlement, funds-in, and funds-out operations. So our central ledger is not a business accounting, it is an accounting of the clearing and settlement of inter-institution transfers. The purpose of the Mojaloop ledger is to account for all operational use of participant funds by the automatic switching machinery up to and including the settlement instructions provided to the trust-holding institution. It is not to provide business accounting for the switch company. — Miller Miller Abel ***@***.*** On Nov 19, 2025, at 2:23 AM, James Bush ***@***.***> wrote: bushjames left a comment (mojaloop/design-authority-project#128) <#128 (comment)> @PaulGregoryBaker <https://github.com/PaulGregoryBaker> raises a point that recording liquidity in the switch ledger as a liability could cause confusion and is hard for lay-people to understand. In Paul B's experience no schemed hold liquidity funds in accounts they control, and thus liquidity is not a liability for the scheme operator. @PaulMakinMojaloop <https://github.com/PaulMakinMojaloop> agrees that it is possible/likely that liquidity funds will not be held in accounts that the scheme operator controls. Contractual obligations can allow DFSPs to hold their liquidity in their own accounts. JB suggests taking this query to the TGB for further discussion before implementation of the CoA moves forward. JB will facilitate the conversation. — Reply to this email directly, view it on GitHub <#128 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6OJ6EOZGWG6SJOZLYY5HD35RAKFAVCNFSM6AAAAAB6SCOH5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNJRHEZTQMRQGE>. You are receiving this because you are subscribed to this thread.

[MichaelJBRichards]

While it is true that some sub-national implementations, such as Mowali and WynePay, have failed to set up their settlement accounts so that the scheme has the control over them that it needs, this is contrary to the architecture of Mojaloop as I understand it. The switch has to be in a position to make a reliable promise to the payee DFSP that it has confirmed that the payer DFSP has sufficient funds on hand to settle the payment proposed. If it cannot (for instance, if the payer DFSP can take funds out of its settlement account without informing the scheme and leave the switch ignorant of whether the payment can in fact be settled,) then the switch's promise, and consequently the liquidity check, are worthless and such schemes might as well dispense with them. As to the question of schemes controlling withdrawals from settlement accounts, I believe that this is the way TIPS works, and I am surprised to find that it is not the case with DRPP - though the latter case may yet be remediable if it is indeed the case.

In other respects, I agree with @millerabel's points and, in particular, with the distinction he draws between the accounting model and the switch's business accounting. I feel that the accounting model has already been discussed in detail at TGB, and that there is little to be gained by re-opening the discussion in order to address this particular point.

[bushjames]

CoA and TigerBeetle mappings have been further iterated at TGB and evolution workstream. @MichaelJBRichards has updated the CoA simulator to illustrate. This has been circulated to TGB/accounting experts for comment in the coming days. Update expected soon.

[bushjames]

TigerBeetle integration design is scheduled for presentation to the DA week commencing 16th March 2026.