Money has to move. The rules around it have to hold.

Moving money reliably from obligation to completion.

BOCA could eventually support several kinds of financial activity. Participant contributions may need to be collected, practices paid, Rootline loans funded and repaid, and other services may create additional transactions over time. The infrastructure behind those payments needs to move money reliably, preserve a clear record of what occurred, and support the conditions attached to each transaction.

Use the rail that fits the transaction

Established bank, card, and payment systems may remain the best choice for many transactions. Newer financial rails could become useful where they offer a specific advantage—such as faster settlement, operation outside traditional banking hours, fewer intermediate steps, or the ability to check defined conditions before funds move.

Different transactions may justify different infrastructure. A routine patient payment may need little more than a reliable conventional payment service. A more complex transfer could benefit from programmable rules that verify the recipient, amount, authorization, or other conditions before settlement occurs.

Contribution and accumulation / More than one way to build resources for care

Financial infrastructure could eventually support more than recurring contributions. A member could also authorize purchase round-ups, other micro-contributions, cash-back or rewards, employer or third-party contributions, or a percentage of variable income. Similar rules could operate through conventional bank and card activity or, where useful, compatible digital-value rails.

A $7.56 purchase, for example, could create a $0.44 authorized contribution toward dental care, subject to limits the member sets. Those small amounts would not need to move individually every time a purchase occurs. BOCA could record them, aggregate them, and settle the combined amount periodically through the appropriate payment infrastructure.

Low-friction should remain transparent. People should be able to see what has accumulated, where it came from, set limits, pause or change permissions, and understand where the value is going.

The rails on each side would not have to match. A member might contribute through a bank account, a card-linked rule, or a stablecoin wallet while a dental practice simply receives dollars into its existing bank account. The purpose is to make it easier for people to build resources for care and easier for practices to receive payment.

When linked actions need to settle together

Some future BOCA transactions may involve exchanging one asset for another—for example, converting a treasury asset into a stable payment asset, rebalancing between financial assets, or using eligible assets to access liquidity.

Atomic settlement could allow both sides of that exchange to complete together or not at all. That can reduce the risk of one side transferring while the other side fails to complete.

Programmable and atomic settlement could also reduce some manual coordination and reconciliation work. They would not eliminate fraud, counterparty exposure, custody risk, network failures, stolen credentials, or other operational risks.

The standard should be practical advantage: use newer settlement infrastructure where it makes a financial function more reliable, efficient, or easier to coordinate, and use conventional rails where they already perform the job well.

Defined financial conditions can be checked as transactions occur.

Some financial activities depend on rules that are known before money, assets, or collateral move. Those rules might define transaction limits, approved recipients, contribution caps, reserve-transfer conditions, collateral commitments, release conditions, approval thresholds, or when an authorization expires.

Where useful, those conditions could be built into deterministic software or selected smart contracts so the system handling the transaction checks them before execution. That could make financial rules more consistent, reduce manual handoffs, and create a clearer record of which conditions allowed a transaction to proceed.

The same approach could apply to participant-authorized contribution rules. Someone who chose to round up eligible purchases, for example, could set a monthly limit that the system would enforce automatically as contributions accumulate.

Rootline provides another possible example. Its proposed practice-backed financing option could involve a defined financial commitment, limits on a practice’s exposure, pledged collateral, and rules governing when that backing may be released or applied. Financial infrastructure could help record those conditions, verify that required collateral remains in place, and enforce selected rules consistently. Rootline would still govern the lending relationship, underwriting, servicing, and dispute processes.

Changes, exceptions, and disputes would still require defined authority and reliable processes. Programmable rules can enforce conditions they have been given; they do not decide whether the underlying policy is fair, legally appropriate, or financially sound.

Conventional databases, signed instructions, credential systems, and established payment controls may perform many of these jobs well. Smart contracts or other programmable infrastructure should be used where they provide a meaningful advantage in consistency, verifiability, coordination, or shared enforcement.

Making existing pools of value more usable.

BOCA may eventually need infrastructure for holding treasury assets, managing liquidity, coordinating capital pools, and using eligible assets as collateral. Newer financial infrastructure could make some of those resources easier to verify, move, pledge, or connect to productive uses elsewhere in the ecosystem.

Using an asset without selling it

Bitcoin provides a simple example. An asset holder could potentially pledge Bitcoin as collateral to access liquidity without selling the underlying asset. Through an appropriate financing arrangement, that liquidity could then support another productive use—including, potentially, capital available to a financing platform such as Rootline.

The value already exists in the asset. The opportunity is to make that value easier to connect to other financial activity.

This is already moving into mainstream finance

BlackRock CEO Larry Fink has argued that “Every stock, every bond, every fund—every asset—can be tokenized.” BlackRock now describes its tokenized Treasury fund as the largest tokenized fund in the world. J.P. Morgan’s Kinexys Tokenized Collateral Network is already designed to let institutions transfer collateral ownership while the underlying assets remain invested.

These are different applications, but they demonstrate a broader direction: major financial institutions are actively building infrastructure intended to make assets easier to represent, move, settle, and use as collateral.

What tokenization changes

Tokenization does not create value, reserves, or capital. It changes how an existing asset, claim, or right may be represented, transferred, verified, collateralized, or programmed.

For BOCA, that could eventually make treasury assets, collateral, capital pools, or other financial resources easier to connect across the ecosystem—including financial activities developed through Rootline and other Cadmus services.

These developments are part of why blockchain and other distributed financial infrastructure remain in Cadmus’s architecture roadmap. Their potential value is practical: providing rails through which assets, collateral, capital pools, and settlement can be represented, verified, and coordinated across systems. Designing BOCA with compatibility for those kinds of rails could allow Cadmus to use useful infrastructure as it matures without having to rebuild the financial architecture around it later.

The next section looks at how shared or public infrastructure could be used while preserving identity, eligibility, privacy, permission, and regulatory controls.

New infrastructure has to earn its complexity.

Financial infrastructure has to work reliably under real conditions. Payments and settlement need to complete as expected; custody, access, and recovery need to be secure; enough liquidity has to be available when obligations come due; and private financial activity has to remain appropriately protected.

The proposed transparency and programmable features also have to produce measurable benefits. Verifiable records should actually reduce reconciliation or improve oversight without creating a misleading picture of solvency. Programmable rules need to behave correctly through exceptions, corrections, disputes, and failures. Different systems and payment rails have to work together where the architecture depends on them.

Tokenized assets, collateral, and other digital financial interests raise additional questions. Their legal rights and ownership need to be clear, collateral needs to be valued and monitored responsibly, and any use of volatile assets has to account for leverage, custody, liquidity, liquidation, and market risk. Shared or distributed infrastructure should also demonstrate that it reduces meaningful friction or dependence on unnecessary intermediaries without creating new concentrations of risk.

The contribution mechanisms explored on this page need evidence of their own. Research would need to show whether round-ups, micro-contributions, rewards, employer support, or other inflows actually increase available resources or participation rather than simply replacing money people would have contributed anyway. The economics of ACH, cards, stablecoins, batching, and other settlement methods also need to be compared at different transaction sizes. People must be able to understand, limit, pause, and reverse authorized contributions, while different sources of value remain clearly distinguishable.

Provider participation matters too. A financial architecture that works for members but creates new technical or administrative burdens for dental practices would lose much of its usefulness. BOCA is being designed so practices can receive payment simply and reliably even when the participant and the practice use different financial rails. Development and testing would need to demonstrate that this can be achieved without creating unnecessary technical, reconciliation, or administrative burden for the practice.

The test is whether a financial technology makes an important function more reliable, verifiable, efficient, flexible, or useful than the available alternatives. New infrastructure has to earn its place through evidence.