dyield™

If you are deciding whether to put USDC somewhere, the question underneath all the others is simple. Who can touch it?

Not who promises not to. Who is technically able to.

We answer that about our own product on a schedule rather than when something prompts us to, because a configuration that is only examined after an incident is not being examined at all. This is how that checking works, and what the most recent pass changed.

What dyield is, in one paragraph

You deposit USDC and receive a token. That token represents your share of a lending vault run by an established manager — Steakhouse Financial or Gauntlet, depending on the product. Your deposit earns from that vault. We take a share of the earnings, published in our Terms & Conditions. Our service is performance-based — we are paid only out of what your deposit earns.

We did not build the vault. We deploy software written and audited by Morpho, without changing a line of it. Our own code is a short list of addresses and settings.

So who can touch it

The answer has two halves, and the first one is short. Your deposit is not ours to move. You redeem directly from the contract, and no balance we control ever holds your USDC along the way.

The second half is the configuration around it — which vault your money is allocated to, and who is permitted to change that. A small set of privileged roles can make those changes. Nothing else in the system can, and no ordinary user, holder or outside party has any route to them.

Some of those changes must wait in public for hours or days before they take effect, and can be cancelled while they wait. Others take effect immediately, by the design of Morpho's contracts. Every change, delayed or not, is recorded on the public chain.

That is the entire surface. Everything else about the product is fixed by contracts we did not write and cannot alter.

The part that is ours, and therefore the part we audit

Morpho's audits cover Morpho's code. They do not cover our settings, and no audit ever will.

Our settings decide which vault your money sits in, who is allowed to change that, and how quickly. That is where the real risk in a product like this lives, and it is entirely ours.

So we treat our own configuration as something to be verified rather than remembered, and we check it on a schedule instead of when something prompts us to.

How we audit ourselves

Three separate practices do this, each with a different job.

Scheduled on-chain monitoring. An automated check reads the vaults' configuration on Base every thirty minutes and records changes that are waiting to take effect, so they are picked up without anyone having to go looking.

Periodic permissions reviews. When we review who can change what, the list of settings to check is generated from the contract's own interface, not from notes. A checklist records what someone thought of on the day they wrote it; reading the contract's interface produces every privileged setting there is, including ones nobody remembered.

Rehearsal before signing. Our procedure is to replay an administrative change against a copy of the live chain before it is signed, then read the result back from the contracts rather than trusting the screen that submitted it. A screen reporting success is not evidence of success.

What the audit established

An earlier version of this article said that nothing about this product can change immediately. That was not accurate, and we have corrected it here.

Many privileged settings sit behind a public delay, and a delay cannot be shortened faster than the delay it guards. Not every setting is delayed: some take effect immediately, by the design of Morpho's contracts.

While a delayed change is pending it is visible on the public chain for the entire window, and it can be cancelled before it lands.

We do not publish the map of which control does what, and there is no reason you should need it. What matters to you is that every change, delayed or immediate, is recorded on the public chain, where anyone can read it.

What a second pass is for

The value of auditing as a system rather than an event showed up immediately.

The first pass was built from a list we had written ourselves. The second was generated from the contract, and it covered settings the written list had never contained — among them the ability to introduce a second kind of fee, one charged against a deposit rather than against what it earns. It was set to zero, it remains zero, and changing it now requires a public delay.

The review found no evidence of exploitation. It also identified gaps in our previous verification process, which we have addressed. Because the list now comes from the contract, the next review does not depend on anyone recalling what to look for.

Where this stands today

We are not finished. We maintain scheduled monitoring and review our onchain configurations. These measures help identify changes and potential issues, but they cannot eliminate smart-contract or operational risk.

Monitoring runs on a schedule, permissions reviews build their list from the contract rather than from notes, and anything either one surfaces is handled on the same terms as everything described above. Security here is a practice rather than a state.

Why we published this

Because the honest answer to that question is never a flat yes. It is: here is what we check, here is how often, and here is what the checking changed.

You do not have to take our word for any of it. The contracts are public, the delays are readable by anyone, and every change we made is in the transaction history. That is rather the point of doing it this way.