Verify the reserve yourself
A stablecoin's central claim is that off-chain assets exist and match the on-chain supply. That claim is worth nothing unless a third party can check it without asking us. This page is the procedure: what to check, which rule requires it, which institution produces it, and exactly what to run.
Read the last section first if you are short of time — several links in this chain are specified and proved but not yet operating, and we would rather you learn that here than discover it.
The chain of custody for the claim "one token, one dollar"
Five independent links. A break in any one falsifies the claim, and each is checkable by a different party, which is the point — no single actor, including us, can assert solvency alone.
| # | Link | Who produces it | Rule that requires it | How you check it |
|---|---|---|---|---|
| 1 | Reserve assets exist and are of the permitted form | The issuer, in a client account or non-objected reserve account | COBS 19A.5.2, 19A.5.3 | Named account confirmations in the monthly attestation |
| 2 | Reserves are segregated per token | The issuer | COBS 19A.6.1 | Account structure disclosed in the attestation |
| 3 | Reserve value ≥ outstanding claims, at all times | The issuer, valued daily | COBS 19A.7.1, 19A.7.2 | On-chain read, any block — see below |
| 4 | An independent party confirms 1–3 monthly, including a random-day reserve test | An independent attestor | COBS 19A.9.1(b)(iv), published under 19A.9.2 | Read the published attestation |
| 5 | An auditor tests reserve composition and controls annually | An independent auditor | COBS 19A.10 | Read the audit report |
Link 3 is the only one you can verify unilaterally and continuously. Links 1, 2, 4 and 5 require a document produced by someone else — which is why the rule puts an independent party on each of them rather than trusting the issuer's own report.
What you can check on-chain, directly
The payment leg exposes the backing invariant as a public read, so the
19A.7.1 test is not a disclosure you wait for — it is a call you make.
// DrUSD.sol
function isFullyBacked() external view returns (bool);
function totalSupply() external view returns (uint256);isFullyBacked() returns reserve >= totalSupply, and an internal assertion
reverts any mint or redemption that would break it.
But be precise about what that proves in the current code. reserve is a
bookkeeping counter incremented on mint and decremented on redemption; no
reserve asset is custodied by the contract. So in this reference implementation
the call is a structural identity — it cannot detect a shortfall in an
off-chain account, because it never looks at one. It becomes a real solvency
read only when reserve is driven by an oracle or attestation feed over the
actual custodied assets. Until then, link 3 of the chain above is checked by
the attestation, not by the chain.
For the yield leg, net asset value must never exceed the assets actually held:
// SdrUSD.sol — `nav` is a public state variable, so `nav()` is its getter
function nav() external view returns (uint256);
function backing() external view returns (uint256);
function previewRedeem(uint256 shares) external view returns (uint256);The check is nav() <= backing(). It exists because we broke it ourselves: an
earlier version booked a coupon into NAV without receiving the cash, inflating
the share price out of nothing.
Read the scope of that guarantee precisely. It holds along the
accrueSettled path, which transfers cash before it books. The contract also
exposes a bare accrue(uint256) that adds to NAV with no transfer and no
caller check, so nav() <= backing() is not an unconditional contract
invariant — it is a property of the intended path. Until accrue is removed or
gated, the on-chain read is a monitor, not a guarantee.
And every settlement that produced NAV is individually inspectable:
// FacilityRegistry.sol
function receiptCount() external view returns (uint256);
function receiptAt(uint256 i) external view returns (Receipt memory);
function collectedBy(bytes32 facilityId, uint256 index) external view returns (address);Receipts are append-only. You can replay every settlement that has ever credited the pool, and check who collected each one, without our cooperation.
The reconciliation you should actually run
Three steps, each falsifiable:
Step 1 — supply against backing, on-chain. Call isFullyBacked() at any
block. Any false is a live breach of 19A.7.1, which also triggers a
notification duty under 19A.7.3. In the current reference implementation this
is a structural check, per the caveat above — the load-bearing version of step 1
is the attestation in step 2.
Step 2 — on-chain NAV against the attested reserve. Take nav()
at the attestation date and compare it to the reserve figure in the published
monthly attestation. These are produced by different parties from different
records; they should reconcile to the disclosed tolerance. A gap here is the
single most informative signal about this system — it is where an off-chain
overstatement would first show.
Step 3 — NAV growth against settlement receipts. Sum the receipts over the period and check that NAV grew by no more than the settlements that actually paid. This is the check that would have caught our own earlier bug.
Redemption is the ultimate test
Every attestation is a report. Redemption is an experiment, and it is the only one that cannot be papered over.
The payment leg redeems at par, on demand, with no queue — that is
COBS 19A.4.1(1)(b), which requires redemption no later than T+2, and the
contract implements it with no queue at all rather than a short one. If a
redemption of drUSD does not settle at par, the claim on this page is false and
you have proved it with one transaction.
The yield leg is deliberately different: it is a share, not a deposit, and its primary redemption runs on a 30-day queue matched to the facility repayment cycle. Anyone promising instant redemption against illiquid private credit is describing a secondary market, not a redemption right — see how Doré makes money for why we state that plainly.
The institutions involved, by name
| Role | Institution |
|---|---|
| Financial services regulator | ADGM Financial Services Regulatory Authority (FSRA) — authorises the issuer and receives 19A.7.3 breach notifications and 19A.4.1(3) extensions |
| Company registry, SPV | ADGM Registration Authority |
| Monthly reserve attestation | An independent attestor, engaged by the issuer, published under 19A.9.2 |
| Annual reserve audit | An independent auditor, under 19A.10 |
| Collateral monitoring on the facility | A monitoring firm approved by the reinsurers, paid for by the borrower |
The rulebooks themselves are public. Sourced provisions lists each document we rely on with its version, its content hash and where to fetch it, so you can confirm we are quoting the same text you are reading.
What is not operating yet
The honest part, and the reason to read this section first.
- Nothing is deployed. There is no contract address on any chain, testnet included. Steps 1 and 3 above are executable against the source and the test suite today, not against a live deployment.
- No attestor or auditor is engaged. Links 4 and 5 of the chain are specified and costed in the plan, not operating. Until they are, there is no monthly attestation to reconcile against in step 2.
- No FSRA authorisation is in place. The regulatory route for the payment leg is proved feasible with conditions on sourced rulebook text; the conditions include an Accepted-FRT determination that has not been sought.
- The fund-side route is unresolved, and the system says so mechanically rather than assuming it — see the ADGM position.
So the correct reading of this page today is: this is the verification design, its rule basis is sourced, and its on-chain half is implemented and tested. It is not a claim that a reserve currently exists and has been independently confirmed. When that changes, it changes by publishing documents, not by editing this page's argument.