How close are we?

A substantial foundation is already there.

The forked Origin Dollar vault supports pDAI, pUSDC and pUSDT. Its vault–token bindings are intact, and the inspected snapshot shows approximately 38.79 million OUSD in total supply. This gives the proposed conversion route an existing technical foundation to build on.

These findings reflect the supplied node exports and local-fork testing from 20 October 2026. Total supply is a snapshot measurement; it does not establish recent minting activity.

Several DeFi systems. Different capabilities.

The investigation spans several established systems with complementary capabilities. Some are directly connected in the inspected OUSD route; others are supporting components whose connections to the proposed mechanism are still being mapped.

About 4.6 percentage points from quorum.

There is a substantial, measurable governance position here. At the 17 October 2026 snapshot, 48Fc ↗ held 2.632 billion veOGV votes, representing 15.4306% of total supply. Its 13 active locks contained approximately 24.052 million OGV, and the voting power was delegated to itself.

That is the basis for saying “48Fc still needs about 4.6%.” More precisely, it needs another 4.57 percentage points of the voting supply counted FOR to meet quorum under those snapshot conditions. This is not a direct estimate of how much OGV must be bought.

How the remaining gap could be closed

Support from approximately 779.50 million already existing veOGV votes would close the snapshot quorum gap without increasing total supply. If 48Fc instead creates additional voting weight through staking or extensions, the denominator grows too: about 974.38 million newly minted voting points would be needed, assuming all other voting supply remains unchanged.

Quorum would be a meaningful milestone. A proposal must also receive more FOR than AGAINST votes and complete the voting and timelock process. Another self-delegated holder, 0xbe2a…d899 ↗, represented 48.31% of supply at the snapshot. Its future participation is unknown, so 20% quorum alone does not guarantee voting control. The timelock adds a minimum 48-hour delay after a successful proposal is queued.

PulseChain block                  27821301
48Fc getVotes (raw)                2632310038158365479696013379
veOGV totalSupply (raw)            17059067205436795787816528884
48Fc share of total supply        15.4305625651%
Quorum numerator / denominator    20 / 100
Gap to quorum (derived)           4.5694374349 percentage points
Proposal threshold                10,000,000 veOGV
COUNTING_MODE                     support=bravo&quorum=bravo
Timelock minimum delay            172800 seconds (48 hours)

Address clarification: 0x3cdd07c1… is the Origin Governor; 0x35918cde… is its Timelock. This evidence set does not include a complete proposal-event census, so no claim of “zero proposals” is made. A completed governance takeover or executed vault repair is still to be demonstrated.

The SKY conversion has actually executed.

This is a concrete positive finding. On 18 August 2026, e121 ↗ deployed a local SKY token and an MKR-to-SKY converter on PulseChain, then minted 2,757,151,059 SKY into the converter as its initial inventory.

On 2 September, Ca6f successfully converted 2.314814814583333334 fork-MKR into 55,555.555550000000016 SKY. The transaction burned MKR and transferred SKY from the converter’s existing inventory at a 24,000:1 ratio with zero fee. This establishes a working conversion component through a mined transaction.

Block                     27439234
Receipt status            1 (success)
Caller                    0xca6f9393e88a69ecd9cdf2b1bfb0785aef07cfcf
MKR burned                2.314814814583333334 fork-MKR
SKY transferred           55,555.555550000000016 SKY
Conversion ratio          24,000 SKY per MKR
Fee                       0
Change in SKY supply      0 (payment from existing inventory)

converter.mkr()             0x9f8f72aa9304c8b593d555f12ef6589cc3a579a2
converter.sky()             0x6400fe04cba0d72be2f2e6ece30ba7c591752c45
converter.rate()            24000
converter.fee()             0
SKY.totalSupply()           2,793,851,059 SKY
SKY.balanceOf(converter)    2,752,775,503.444449999999984 SKY
SKY.wards(e121)             1
converter.wards(e121)       1

Contracts: SKY token ↗ · MKR-to-SKY converter ↗. In the captured state e121 is an authorized ward on both. This is relevant control over these local contracts, with a narrower scope than control of the wider Maker system.

Why the MKR permissions need a more precise explanation

MKR reports a zero owner(), but it also has a nonzero authority contract. The successful conversion consulted that authority and completed the burn. So a zero owner does not mean every MKR operation is disabled. The remaining permission questions concern the particular action needed: this burn path does not by itself grant control over Maker’s Pause, Vat or End, or over Origin’s vault.

Simulated caller: Reserve Timelock (separate from Origin)
Main.hasRole(OWNER, Timelock)                 true
Main.hasRole(OWNER, 48Fc)                     false
Main.upgradeTo(currentImplementation)        success (0x)
RToken.upgradeTo(currentImplementation)      success (0x)
BackingManager.upgradeTo(currentImpl)        REVERT
  Proxy: caller is not the admin

Compound, Balancer and Reflexer remain part of the investigation

The wider contract set includes Compound/cToken lending and reserve helpers, Balancer flash-loan references, and Reflexer-style governance or configuration tooling. These could contribute useful capabilities. Their final roles need to be established with executable routes, correct token bindings and units, the required permissions, and available assets. For FLX itself, a direct role in the pDAI/OUSD conversion has not yet been demonstrated.

This is a sophisticated multi-protocol engineering problem. The completed SKY conversion and the mapped Origin governance route are real progress. The next milestone is to connect the relevant parts into a repeatable pDAI mint, redemption or price-correction cycle.

What the $0.998 threshold actually means.

The mint logic accepts an oracle quote of at least $0.998 and caps the accepted mint valuation at $1.00. This threshold is a minimum accepted oracle price—not a minimum deposit balance or a floor under pDAI’s exchange price.

This establishes how the conversion is priced internally. Connecting that accounting value to genuinely redeemable dollar value is an essential next step.

The inspected feeds carry May 2023 timestamps, so suitable pricing and freshness safeguards also deserve attention.

Specific problems. Concrete next steps.

The main identified obstacle is strategy accounting. Three registered strategies revert during balance checks, blocking the ordinary redemption calculation and mint paths that trigger a rebase.

For the Morpho route, the failure has been pinpointed: the forked Aave pool delegates to an implementation that does not implement the required getReserveNormalizedIncome function. This gives the repair effort a specific technical target. Because multiple paths share the Aave dependency, a successful repair could restore several functions together. The other failing dependencies still need equivalent testing.

1. Restore accounting and asset access. Repair strategy balance checks and verify withdrawals of the underlying assets.
2. Establish a valid activation route. Use the verified Origin governance route, or establish another valid permission path, to approve and execute the repair. A proposal must pass; a simulated privileged call alone cannot activate it.
3. Run the complete conversion cycle. Demonstrate minting and redemption, including actual token transfers.
4. Test repeated use and larger withdrawals. Verify liquidity, pricing and accounting beyond a single successful transaction.
5. Connect the wider components. Establish which systems participate in the executable pDAI conversion or price-correction route.

capitalPaused()                  false
getAllAssets()                   [pDAI, pUSDT, pUSDC]
priceUSDMint(pDAI)                1000000000000000000
priceUSDRedeem(pDAI)              1000091780000000000
rebaseThreshold()                1000000000000000000000
autoAllocateThreshold()          25000000000000000000000
calculateRedeemOutputs(1e18)      REVERT: execution reverted (0x)
OUSD.totalSupply()               38787718260595764955684977

Changing a default strategy alone may be insufficient: failing registered strategies must be handled properly, including their withdrawal requirements. Governance and activation are part of the implementation work, alongside the code itself.

Real collateral would change the outlook.

Once the conversion route works, sufficient, accessible and genuinely dollar-valued collateral would substantially improve the prospects for both establishing and maintaining a peg.

That backing could turn an internal $1 valuation into an economically meaningful redemption opportunity. If users can execute a reliable path from pDAI into those assets, arbitrage would have a practical mechanism for bringing market prices toward the redemption value.

The backing must be available after existing claims and sufficient for the redemption commitments being offered. Its quality, accessibility and liquidity matter as much as its nominal size. Flash loans can assist execution, while lasting redemption commitments require lasting economic backing.

The same scenario. Clearer questions.

Assuming the vault is fixed through a workaround and sufficient collateral liquidity is available.

Both panels now use the same core assumptions: the strategy blocker has been resolved, and sufficient, accessible, genuinely dollar-valued collateral is present. Both assessments see a promising construction under those conditions. Differences in the scores reflect separate judgments about the engineering and remaining execution work.

Read these as conditional ratings on a 1–100 scale. A code score of 95 is an estimate of available functionality, rather than an audited 95% completion measurement. A peg score of 85 is an optimistic scenario judgment, rather than a statistically established 85% probability. Operational readiness here refers to the repaired scenario, not the current live state.

The outputs behind the story.

The page combines dated archived evidence. Readouts above are human-readable decodings or explicitly labeled calculations; they are not newly generated terminal sessions. Transaction links point to PulseChain records. The downloads include the selected saved responses, receipts and traces, so the claims can be checked independently.

The Origin compact snapshot is a transcription of decoded RPC results; original governance requests/responses and cached voting results are also included. The January date is a model. Reserve upgrade checks are simulations with a specified caller. No complete Origin proposal history or complete future architecture is claimed.

The page makes no live RPC requests. The existing Simple Analytics tag is retained. Contract state may change after the recorded blocks.