August 2026 Development Update: Preserving Meaning Across Boundaries

Financial workflows become difficult to trust when the same business fact changes meaning as it crosses a database, API, queue, wallet, and user interface. A share can be rounded differently. An accepted subscription can be confused with a fulfilled deposit. A delivery receipt can be mistaken for a completed reaction. In August, we worked on those boundaries so the system keeps more of the original meaning as work moves between services.

The design goal is fewer ambiguous handoffs for fund managers, operators, and partners to interpret. The changes below improve the model and the recovery paths.

Make share precision a shared contract

We migrated share-related database contracts to exact decimal representations and aligned the investment and distribution services with canonical decimal shares. Shared event strings, frontend handling, generated SDK contracts, and the functional specification were updated around the same rule. The migration work also addressed fractional shares and uniqueness for distribution reports.

The mechanism matters because rounding at one boundary can produce a different quantity at the next boundary. A canonical decimal contract gives each service the same representation to validate, store, calculate, and display. It helps teams investigate a disagreement by asking where the value changed, rather than wondering whether each consumer applied a different conversion. This is precision infrastructure; it is not evidence that live balances have been reconciled or that a particular fund’s valuation is correct.

Separate acceptance from fulfillment pricing

We clarified the ownership of pricing decisions in the fund-manager service. Manager acceptance records the decision and its note or timestamp, while subscription pricing moves into deposit fulfillment. When the known dealing price is available at fulfillment, the workflow uses it to determine price per share and mint quantities, while provider and platform statuses remain distinct. Further changes support recording NAV directly and carrying manager-set pricing through the fulfillment path.

This ordering gives operations a cleaner explanation for a common exception: an investment may be accepted before the price used to fulfill it is known. The system can preserve both facts without silently repricing an earlier decision. The change improves responsibility and auditability in the workflow; it is not a universal valuation guarantee and still depends on the governing fund process and the data supplied at fulfillment.

Point recovery at the recorded reaction

We added atomic audit support for domain reactions and bounded retry behavior. The retry service now targets a recorded failure for the specific delivery service and activity, using the event identity rather than broadly replaying an entire queue item. Related service work added audit and status handling across escrow, filer, KYC, wallet, email, and EVM reactions.

For a support or operations team, this creates a more useful recovery question: which service failed to react to which event, and what evidence should be checked before retrying it? It also preserves an important distinction. A receipt says that a message was delivered; a reaction says that a service processed it; neither alone proves a completed financial action. The recovery path narrows the operation to a known failure, while reconciliation remains responsible for confirming the resulting business record.

Let the interface represent waiting

The Tahoe frontend gained notification-socket handling that invalidates and refetches lifecycle views when custody updates arrive. In a related admin view-model change, a pending custody next-operation wait remains open while a slow backend is still working instead of failing after the earlier polling limit.

This connects the interface to the workflow’s actual state. An operator can keep a pending action visible and receive a refresh path when new information arrives. The design goal is to avoid repeated commands simply because a response took longer than the screen expected. External delivery, provider timing, and reconciliation still determine when a pending state can become a confirmed business result.

Keep product and release boundaries legible

We also clarified which SDK and investment-runtime packages own shared contracts, restructured shared investment and dashboard code, and improved frontend worker runtime reconciliation and immutable image publication. User invitations gained required onboarding-form context and profile custom fields, while wallet and vault handling received custody nonce atomicity and reconciliation hardening.

Together, these changes tell an operator where a contract lives, which runtime record is being reconciled, which invitation data must travel forward, and which custody operation needs its own nonce. They are development and release controls in the codebase. August’s development status gives partners a more precise basis for reviewing data ownership, exception recovery, and the evidence needed before a workflow is considered complete.