How Mercery works

Status: Built, runs on simulatorStatus: Built, runs on simulator

Mercery connects agreed terms, a raise, income verification and payments that stop at a defined limit. This section explains what each stage does and where the checked implementation still depends on unresolved decisions.

An issuer creates a series. Backers acquire units associated with it. The terms define the threshold, the rate per unit and the cap. A report then connects the income calculation to those terms, and the payout vault records amounts available to holders.

Read the lifecycle as separate stages

The main sequence is issue, raise, release, verify and pay. Retirement and buy-back are different ways the ordinary payment path ends. A hardship pause, an amendment or extinguishment follows a separate path; none should be treated as an ordinary payment.

This is a map of stages, not a transaction schedule or one shared state machine. Release and reporting have separate rules. The raise has its own states; retirement, buy-back and extinguishment concern the income lifecycle. Ending ordinary payments does not mean every claim has been collected.

The detailed explanations are being reviewed against the recorded differences. Pages that change who receives money or what someone must do remain unpublished drafts until the relevant decision is resolved. This overview does not turn those drafts into approved product rules.

For exact source-derived structures, use the program reference, contract reference and status values. Those pages describe the code that was checked, rather than a deployed service. The parameter explanation remains held for review.

One illustrative series

The shared example uses 1,000 units, an illustrative share rate of 6% and a threshold of $40,000.00. These are inputs to a worked example, not terms offered to anyone.

$$O(Y)=\lfloor rNY_{\mathrm{excess}}/W\rfloor,\qquad Y_{\mathrm{excess}}=\max(0,Y-\theta)$$

Formula

Here, the fixed-point rate is r, the unit count is N, and W is the code's fixed-point scale. The calculation first finds the income above the threshold. The quarter's calculation takes the difference from the previous year-to-date result. Nothing due this quarter shows why a zero result is normal.

What each side sees

The backend data map keeps income openings separate from the records shown to backers. Payment amounts and status events are public onchain. Backers receive statuses, not personal reasons; a status cannot explain someone's circumstances.

What can go wrong

A correctly calculated example does not settle legal terms, remove software defects or establish that the system has been deployed. Read the status badges and distinguish source behavior from rules awaiting a decision. An income-linked payment can be zero, and a holder must not treat the cap as a promised payout.