Stopping, restoring and completing an exit

The important question is whether the next step reaches payment

The controller reading now supports a more precise distinction between an instruction that must wait, continuing permission to invoke a function immediately, cancellation of a pending instruction and administration of those permissions. It also sharpens a practical conclusion: a fast stop does not establish an equally fast restoration. A restored permission still does not collect a loan, release a fund redemption or supply the asset needed for a customer payout. Source-supported authority; the separate payment boundary.

Two other findings change the earlier interpretation without closing its gaps. The candidate MetaOracle at two differently linked repository revisions has the same file identity, so that pointer difference cannot explain the recorded deviation mismatch. A later reviewer statement reports a fresh timelocked PSM deployment, advancing the documentary status beyond the original test-plan wording, but without identifying and verifying a funded production route. The excluded source-version explanation; the deployment statement and its limits.

For a holder, these are not abstract distinctions. An eligible redeemer can wait for service restoration while cash exists elsewhere. A borrower can need USDC before pledged sUSDe is free to begin cooldown. A local lender can receive an oracle price without a funded buyer for the collateral. The protective countercases matter too: a valid delayed instruction, a functioning unaffected operator, independent repayment funds or already-local payout stock can each help—within the part of the chain they actually serve. Notice versus complete exit; local funding conditions.

What does the controller authorize?

The newly obtained address-indexed source concerns Ethereum controller 0xe8dc0fab349ea169283c48ccfd09d797e6db7c94, not the complete Mint V2 contract. The provider returned the custom controller and the relevant inherited scheduling, access-control and call-handling bodies. A pinned public Guardian repository supplies a corresponding custom controller and its design README. This strengthens source-level interpretation; it is not an independent compilation-to-runtime match or a current enumeration of authorized actors. The connection to the USDe/Mint family remains the earlier, dated ownership and administrator evidence. Address-indexed scope; pinned public source; earlier bindings.

A scheduled instruction is not the same permission as an immediate function

In the examined source, ordinary execute and executeBatch use the inherited scheduling machinery. A scheduled operation binds its target, value, full payload, predecessor and salt, or their batch equivalents. A proposer creates that specific operation; the requested delay must satisfy the minimum at scheduling. Execution then requires an eligible executor, readiness and completion of any required predecessor. An executor does not gain permission to substitute an unrelated instruction merely because some waiting period has elapsed. Custom and inherited source.

The separate immediate entry points require a whitelist-executor role and an allowed target plus function selector—the identifier of the function being called. That is continuing permission over an action class, not an ordinary scheduled approval of every argument in a single business instruction. The target still has to enforce its own caller, argument and application constraints. The custom introduction is less precise than the function bodies about which entry points use this path; the distinction here follows those bodies. Controller source and declared design.

Behavioural basis: the four inspected controller/dependency bodies. Dated actor/target connections: 18 September control evidence. Source interpretation is not transaction testing.

There are two further qualifications. The inherited ordinary executor gate can be open when the executor role is granted to the zero address, but that does not remove scheduling conditions and its present configuration was not established. Likewise, initial constructor roles are not a current actor inventory. Neither a Safe signature threshold nor absence of a complete roster establishes organizational independence, absence of execution alternatives or a closed control path. Scheduling and role scope.

A fast stop is not evidence of a fast restart

The 18 September observations found selected immediate Mint permissions for role revocation and customer admission/removal, while the sampled grantRole whitelist entry was false. The new source reading explains why those are different authorizations. It is therefore inappropriate to assume that the observed fast revocation path also provides fast re-granting. It would be equally wrong to infer that every possible restoration must wait one day: alternate current paths and the complete Mint body remain unresolved. Dated permissions; separate execution paths.

Restoration may need another valid authorization, a scheduled operation that becomes ready, a functioning executor and a target that can complete the intended action. The examined scheduling body supplies no general maximum time by which a ready instruction must be executed. Cancelling an instruction removes that pending operation; it does not perform its business purpose, replace a replenishment or repay a waiting holder. These are source-level implications, not a reconstruction of an actual cancelled Ethena payment. Operation state and call handling.

The benefit is real: separating containment from expansion of authority can reduce damage while retaining deliberation for broader changes. An unaffected operator with usable inventory may continue to serve unaffected customers. The corresponding cost is route-specific: a legitimate customer can miss a deadline while the permission or resource their route needs is restored. No service-recovery duration, customer-priority rule or current outage was measured here.

Notice has to outlast the complete exit—not just the cooldown

An ordinary operation’s earliest readiness and a holder’s earliest cash arrival are different clocks. If an operation is scheduled at time s with required delay D, the source model permits execution no earlier than s + D. It does not require execution at that instant or bound how much later execution may occur. It also does not ensure that a holder learns of the action at scheduling. Ordinary scheduling.

For a holder using the route release collateral → begin a new cooldown → claim USDe → convert into the needed asset, a necessary timing relation is:

Cash arrival cannot precede:
notice received + time to release collateral + remaining cooldown + time to claim and convert.

This relation combines the examined scheduler with the previously established claim sequence. It assigns no measured duration to detection, repayment funding, issuer acceptance, custody release or market execution. Several steps can involve different entities and networks. A promise about one segment is not a promise about their sum. Staking and collateral-release sequence; funding and holder eligibility.

Under the 18 September configuration, both the controller minimum and the staking cooldown were 86,400 seconds. A holder who starts a new cooldown at the start of a minimum-length window has no positive time margin from those two durations alone. Detection lag, debt repayment before collateral release, transaction inclusion and the final sale or issuer redemption cannot all be assumed away. This is a necessary-condition comparison, not a new parameter reading, adverse simulation or a claim that every action executes at its first ready moment. Dated controller/cooldown record.

The countercases change the route. Already-free USDe can have fewer remaining steps. An existing cooldown may have less time remaining. Independent debt funding can release pledged collateral earlier. A usable secondary sale of free shares is different from finishing the cooldown. A deliberately longer operation delay can provide more room. Each still needs actual availability, an acceptable price and any required eligibility; none creates a universal escape guarantee. Position-specific exit routes.

For a lender, the relevant deadline may be earlier still. A borrower cannot fund repayment with proceeds that become available only after the debt has been repaid enough to release collateral. A stable-looking oracle value or a full eventual backing recovery does not resolve that ordering. Conversely, timely outside repayment can replenish lender liquidity and interrupt the stress chain. Timing, impairment and independent funding.

A successful controller call is not a receipt for every downstream asset

The examined ordinary and immediate call paths use Address-library handling that propagates target reverts. The batch path does not deliberately continue past a reverting member, and an ordinary operation does not become done simply because its delay elapsed. These are useful source-level constraints. They were not demonstrated with a transaction or rollback test in this continuation. Call-handling and operation-state source.

That helper does not interpret every target’s business-specific return value as evidence of the intended commercial outcome. Completing an authorized call therefore cannot be substituted for the relevant application result, asset transfer or off-chain receipt. Ethereum transaction behaviour also does not make a loan notice, custody instruction, hedge or bank transfer roll back as part of the same operation. The library’s actual boundary.

The 20 September study remains a useful, narrower payment observation: standard logs matched a USDe burn and an outbound USDC transfer in one provider-reported mined transaction. Its candidate Mint event did not match the client ABI and a separate receipt/status was not obtained. No controller source, later audit title or role event resolves those missing facts. The pairing is not a newly verified redemption count, a fee determination, a throughput statistic or proof that Maple or JAAA funded that payment. The original payment evidence and limits.

Resource and legal limits are inherited from 20 September recovery research; controller interpretation is from 26 September source reading. No new balance or legal mandate was obtained.

Two repository revisions contain the same candidate oracle

The selected Base market remains the earlier identified USDC loan against USDe, with meta-oracle 0xf4b17c79492d68775e22e8dd0a2bb22854a39a47. The new work did not refresh that market binding or identify its full current implementation lineage. Instead, it examined a specific source-version explanation: did the README’s different factory-linked commit supply a different MetaOracle body? The original Base binding; the two source identities.

It did not. The MetaOracle file at 36385342274f71999b66c79c4475234a39ba9a01 has Git blob 56b2417be1ea52c16ccc193fb4efeb5830f95dfd, the same blob recorded for the candidate at 5ce0e80adb69bc06f5b390032150e7ea41d30c02. Both use the average of the two prices in the relative-deviation calculation. The difference between these two commit pointers, by itself, is excluded as an explanation of the earlier returned deviation. Neither file identity proves that this body was installed at the selected address. Pinned source evidence.

The earlier study recorded that a backup-price denominator matched that one output. Such a match does not identify the complete deployed algorithm, validate all exceptional behaviour or establish a preferred denominator. The concrete discrepancy remains. Original comparison and interpretation.

The inspected candidate factory creates and initializes a clone within its deployment function. That is positive evidence about its intended creation sequence, not a record that it created this instance. The publisher’s indexed product documentation and saved README also list different Base factory addresses. No migration, replacement date or authority over the existing selected instance is inferred from that difference. Factory lineage, initialization and current configuration remain separate missing links. Factory source and documentary locators.

A more precise policy matrix—still conditional

Basis: candidate MetaOracle and factory source. The full inherited initialization/clone bundle was not rebuilt or established for the selected deployment. Neither source tests nor live switching were executed.

Price validity, stored selection and cash recovery must stay separate. The inherited Base backup used USDe/USD without an observed USDC/USD denominator; it was not automatically a direct valuation in the loan asset under every USDC move. Par-oriented valuation may spare a borrower liquidation during a recoverable discount, while exposing a supplier to lower or inaccessible proceeds. A market-responsive value may recognize impairment earlier but force realization of a temporary discount. Neither policy manufactures the USDC needed for repayment. The Aave share-ratio/capped-USDT comparison also retains its own dates and cannot be replaced with a USDe spot-depeg assumption. The distinct installed-input evidence and creditor consequences.

The PSM record now includes a later deployment claim

The original Kairos review, dated 22 July 2026, assessed a 15 July integration test and conditionally supported a 20 million-USDe seed. A newly inspected Kairos contribution dated 28 July reports that Ethena moved to a fresh timelocked deployment. That is positive documentary evidence beyond the earlier future-tense plan. Original review; later statement.

The supported status is “reported fresh deployment; production relevance and condition closure unverified.” The later contribution does not identify the fresh instance, establish its network/configuration or supply the pre-seeding confirmation record. Its posting date is not a proven deployment or seed date. The July test address and mainnet USDtb comparator must not be relabelled as a verified production Base USDe PSM. The September 22 chapter correctly preserves what its earlier reading established; this continuation adds the later statement without rewriting that account.

Condition set: the retained documentary chapter and the July review. New status evidence: 28 July reviewer statement.

A local swap and continuing local capacity have different dependencies

A customer may benefit when the needed payout asset is already local, uncommitted and accessible to the permitted swap. That individual exchange need not wait for a new cross-chain transfer. Restocking the facility is another chain. It may still require an issuer-side action, external asset release, conversion and a source–Base transfer. Atomic local exchange is therefore not synonymous with bridge-independent continuing capacity. This is reasoning from the reported design, not an observation that a production route stopped or exhausted inventory. Reported local-conversion model; cash-arrival discipline.

Admission and valid execution are prerequisites. For a specified eligible customer, payout asset, custody location and horizon, before an additional funded arrival, a necessary bound is:

Payout cannot exceed the least of:
usable uncommitted inventory; usable transfer authorization; payout permitted by remaining applicable limits.

This is a bookkeeping and control condition, not an implemented PSM formula or a measured capacity estimate. Its terms must be expressed in compatible units. A cap in USDe or a dollar notional needs the actual applicable conversion rule before comparison with an inventory of a different token. A custodian balance, an allowance to transfer it and permission for this customer to use the route are three separate facts. Tokens outside the PSM address are not automatically inaccessible; assets under a related brand are not automatically spendable by it. Custody and limit conditions; asset/entity-specific accounting.

A larger USDe float does not, by itself, enlarge the opposite-side payout stock. The float can support distributing USDe to customers contributing collateral; a customer leaving for USDC needs available USDC. A reserve covenant is not immediate transfer authority over that stock. An unchanged oracle price also does not preserve admission or usable approvals, and a cap does not reserve inventory for the next customer.

A genuinely funded local stock is a useful countercase: it can cover a timing gap while an unrelated loan or fund claim remains unsettled. Count that stock once. Future replenishment remains a receivable until received, and any financing must carry its matching debt or assigned claim. Maple and JAAA proceeds do not become Base PSM inventory merely because the issuer could eventually recover them. Independent funding and conservation.

The remote supply boundary is still separate. Earlier Base owner, controller, endpoint and peer observations did not establish all source locks, remote supply, in-flight messages or effective verification settings. A same-hex peer is not a proven self-loop. Under a lock/mint model, comparing one source balance with one network’s supply needs compatible units, peer coverage and timing; an unexplained difference cannot simply be labelled backing loss. No corridor reconciliation or all-chain supply ratio was produced in this continuation. Original representation scope.

Newly located audit artifacts are not newly inspected audit findings

The auditor’s own engagement narrative and repository listings add provenance leads for an execution guard, onchain minting and a later PSM adapter. Their original PDF bodies were not obtained. Consequently, there is no new original-body assessment of findings, remediation, reviewed commits or installation at the selected production objects. A named original artifact is stronger discovery evidence than a logo, but it is not equivalent to an inspected report. Auditor narrative and exact artifact identities.

Product boundaries matter. The newly read onchain-minting narrative concerns xUSD; other entries concern a Safe guard and a PSM adapter. Those are not automatically Ethereum USDe Mint V2, the Base USDe token or the selected MetaOracle. A shared Ethena label cannot transfer an audit across those objects. The newly located August 17 adapter-review filename does not supply its production address or connection to the selected Base corridor.

The PSM summaries also differ. Kairos attributes three Medium, nine Low and nine Informational findings to the described July 2 report; Guardian’s indexed summary lists one Medium, three Low and five Informational for its June PSM entry. Without matching original bodies and review/fix identities, the investigation cannot decide whether these are different scopes, stages or inconsistent descriptions. The counts are not averaged, and neither is adopted as an inspected finding set or current risk score. Kairos attribution; Guardian attribution and access scope.

The earlier inspected Pashov and selected Code4rena material retains its own scope and dates. Likewise, locating a Cantina MetaOracle PDF artifact does not establish that the selected instance uses the reviewed version. Meaningful review evidence should neither be dismissed nor enlarged into a guarantee covering source–deployment identity, actor configuration, external recovery and funded exits. Earlier inspected audit scope; new artifact-only lead.

What changed—and which conclusions still need evidence

The wider authority, valuation and remote-control assessment remains partial. That does not mean every control fails. Ordinary scheduling restrictions, separation of immediate use from policy expansion and the later deployment claim are meaningful evidence within their scope. Missing correspondence and configuration prevent the stronger deployed conclusions—not the use of these narrower findings.

The most decision-changing next evidence would tie the selected Mint and Base objects to versioned production implementations and effective authority, resolve the selected oracle’s lineage, and identify the PSM launch/condition record. Independent repayment, free-collateral and funded-sale evidence can answer other creditor questions without presuming these protections are complete. A current aggregate audit count or an unchanged market price cannot substitute for either kind of evidence. Current coverage and limits.

Sources, versions and inspection boundaries

Public material below was read for the source-based continuation on 26 September 2026, except where explicitly inherited. Access dates are not deployment dates. Indexed publisher text is identified as such. Related publications from one issuer or reviewer are not independent corroboration. The original September 22 documentary register was not refreshed and is not a current permission inventory.