A 50/50 Revenue Split With a 100/0 Loss Split: Inside Sentora's Aave V4 Hub Proposal

The arithmetic is three numbers. Sentora proposes to operate an isolated Aave V4 Hub. Sentora takes 50% of protocol revenue. The Aave DAO takes 50%. The suppliers who fund every loan take 0% of the revenue and absorb 100% of the liquidation deficit. This is not a reentrancy bug. There is no integer overflow, no unchecked external call, no memory-safety defect. It is a governance architecture problem, and that class is harder to patch because the exploit is a vote. In 2017 I spent six months disassembling EVM opcode execution flows to locate the DAO's reentrancy path. One rule survived that work: read the incentive table the way you read the assembly. The instruction pointer does not care about your intentions. Neither does a revenue split. The proposal is an ARFC, an Aave Request for Comment, the first stage of the governance pipeline: ARFC, then Snapshot, then AIP. Nothing is live. Aave V4 has not shipped. Hub-Spoke is the stated V4 direction: a Hub holds liquidity, Spokes originate credit against it. Sentora would operate one Hub as an independent entity, with multiple Spokes drawing from Sentora's suppliers. The permission matrix is the load-bearing structure. The Aave DAO retains contract ownership. The Governance Short Executor holds the admin role over the Hub, the Spokes, and the AccessManager. Sentora holds an operational role. That role executes risk-reducing actions instantly: pause or freeze reserves, halt assets or Spokes, lower collateral factors, tighten supply caps. For risk-increasing actions, raising parameters, adjusting interest rate curves, changing liquidation configuration, there is a 48-hour delay. Read the matrix as a state machine. There are two transitions. The tightening transition fires in block N. The loosening transition fires at block N plus 48 hours. Both are valid. Neither is reversible inside the window. During those 48 hours, the DAO has no mechanism to cancel a single queued operation. The only recourse is to revoke Sentora's role entirely, and that requires a separate on-chain AIP that takes days to weeks. The emergency brake is not a brake. It is a referendum. Sentora does not own the contracts. That is true, and the proposal states it. But owning the contract object is not the same as controlling the operational state. Who chooses the collateral set, the interest rate model, the liquidation parameters, the oracle? The operator. Ownership is a title. Control is a function call. Context matters for the comparison. Aave V3 runs as a monolithic market with multiple independent risk providers publishing parameter recommendations and monitoring positions continuously. That model is imperfect, but it is adversarial by design: several parties watching one book, none with unilateral execution power. The Sentora proposal replaces that with a single operator on one Hub. It is a shift from distributed vigilance to concentrated discretion. Whether that is an improvement depends entirely on the operator's real-time capability, and the ARFC provides no evidence about that capability. It describes the operator's powers in detail. It does not describe the operator's monitoring. Decompose the design into two halves, the way I would decompose a circuit. First half: the revenue split. Sentora takes 50% of reserve-factor revenue plus protocol liquidation fees. The DAO takes 50%. The proposal specifies no first-loss layer. Sentora contributes no capital to a junior tranche. It posts no bond sized to the exposure it manages. It does not sit behind the suppliers in the loss waterfall. In traditional fund structures this is performance fees without a drawdown: the manager earns on the upside and contributes nothing to the downside. I am not calling it a Ponzi. I am calling it a moral hazard with a clean interface. Second half: the loss split. When a Spoke reports a deficit, borrower collateral exhausted and debt still outstanding, the shortfall is recorded against the Hub's asset and absorbed by that asset's suppliers. Not by Sentora. Not by the DAO. Not by an Umbrella reserve, because Umbrella coverage does not include this Hub. Not by a deficit backstop, because the ARFC specifies none. The supplier is the residual claimant of last resort, standing at the bottom of a waterfall with one name on the liabilities side and no name on the protection side. Now the monitoring layer. The proposal explicitly excludes Aave's existing risk service providers from this Hub: from monitoring, from parameter recommendations, from incident response. That produces a specific and dangerous state: no party is designated to watch the risk, but any party is permitted to object. Silence in the review window does not prove that anyone reviewed the change. It proves only that no one was required to. I have seen this pattern. In 2021 I ran 10,000 concurrent mint and transfer simulations against fifty NFT marketplaces and found that 60% failed the optional royalty standard, not because developers were malicious, but because nobody had been assigned the job of checking. Unassigned responsibility is not shared responsibility. It is zero responsibility distributed evenly. Now the scale dimension. The proposal imposes no ceiling on Hub growth and no cooldown between parameter updates. There is no rate limiter on risk accumulation. A compromised or hostile operator can raise exposure across multiple markets in a single batch, and the DAO's observers get 48 hours to detect it, inside a window where the only remedy, role revocation, cannot execute. A circuit that accepts unbounded input without a constraint is not a circuit. It is an invitation. The isolation design deserves its own paragraph. The Sentora Hub holds no credit line with any other Aave DAO Hub. Spokes draw only from Sentora's own suppliers. Proponents frame this as containment: a deficit here cannot spread elsewhere. The framing is correct, and it is also the problem. Isolation cuts both ways. It keeps the infection from leaving and keeps the liquidity from entering. When this Hub develops a hole, there is no neighboring pool to borrow from. The supplier is not buffered. The supplier is the buffer. The source material puts it precisely: this does not protect suppliers inside the Sentora Hub from their own Spokes. The asset set compounds it. The Hub lists RLUSD, PYUSD, and OUSD, and excludes USDC and USDT. USDC and USDT carry the deepest liquidity and the most battle-tested oracles. Excluding them is a choice. It may be compliance-driven, since RLUSD and PYUSD are both NYDFS-regulated issuers. It may be risk-driven. Either way the consequence is a thinner market. Under stress, thin borrow-side liquidity converts failed liquidations directly into supplier deficits. The oracle configuration for OUSD remains unconfirmed in the proposal. That is a disclosure gap, not a rounding error. You cannot price what you cannot verify. And the spec is not frozen. The narrative says USDe and PST back the first RLUSD yield loans, with PRIME and mWIN added later. The specification table lists four assets. A Bluechip description says RLUSD is collateralized by kBTC; the table says RLUSD, PYUSD, OUSD. These are not typographic differences. They are evidence the proposal is not finalized, that suppliers are asked to assess a risk surface still being drawn. Run the failure scenario forward. OUSD price deviates because the oracle is unconfirmed. Liquidations fail to execute because the liquidation config was set by the operator. kBTC collateral falls fast. The borrower's collateral is exhausted; the debt survives. The Spoke reports the deficit to the Hub. The Hub records it against the asset. The suppliers of that asset absorb it: no first-loss layer, no Umbrella, no backstop. Then the DAO starts the revocation process, which needs its own AIP, which takes days or weeks, by which point the loss is already realized. I audited L2 fraud-proof mechanisms in 2022 and modeled exactly this class of gap: how an insufficient bond and a slow dispute window turn a theoretical security assumption into a real loss. The pattern is identical here. The protection exists on paper and expires in time. One more mismatch is worth logging. The Sentora CEO published a November 2025 argument that risk management requires measurable controls and continuous monitoring. That is a defensible principle. But this proposal removes the existing monitoring providers from exactly that role. The stated doctrine and the proposed architecture do not reconcile. Either Sentora believes it can monitor better than the incumbents, in which case the proposal should describe how, and it does not, or the design and the doctrine are in tension. Code doesn't lie; audits do. A proposal is not code yet. That is precisely why it must be read. The consensus read will be favorable, because the proposal looks like decentralization. The DAO retains ownership. The operator role is revocable. The DAO keeps 50%. All three statements are literally true. All three are structurally hollow. Ownership without control is a title. Revocability without immediacy is a promise. A 50% share of revenue on an asset you also fully expose is not a hedge; it is a fee paid to the party holding the risk. The trust model here is not a bug in the code. It is the code. Trust is a bug, not a feature, and this proposal ships the bug as an architecture diagram. The contrarian position is not that Sentora is malicious. It is that the design does not require Sentora to be good, and it does not require anyone to be watching. That is the defect. The DAO was a warning we ignored: an elaborate governance structure that felt like protection until the moment it needed to be one. The question before any Snapshot vote is narrow and answerable: will the DAO grant operational authority without designating an independent observer and without declaring a first-loss protection? If yes, the supplier becomes the insurance policy. If no, the proposal returns to draft. I forecast the vote proceeds, the deficit stays hypothetical through the next leg up, and the first real test arrives on a weekend when the oracle lags and the 48-hour window cannot save anyone. Zero knowledge, maximum proof. Here the proof is not cryptographic. It is the loss waterfall. Read it from the bottom up.