# Why Divigent Divigent is purpose-built yield infrastructure for agent wallet working capital. Agent wallets are not passive accounts. They hold USDC for payments, execution, settlement, subscriptions, API calls, and other operational needs. Some capital must remain immediately liquid. The idle portion can be deployed productively until it is needed again. Most yield products were designed for users who intentionally deposit capital and tolerate manual withdrawal timing. Agent wallets require a different operating model: * capital must remain available for payment flows; * routing must avoid short-lived rate noise; * reserve levels must adapt as agent activity changes. Divigent was built around three core differentiators. ## Liquidity Resilience Agent capital must be able to leave the protocol when it is needed for payments. Divigent does not treat liquidity as a static assumption. The router evaluates current venue balances and withdrawal capacity before planning an exit. It reads the router's Aave position, available Aave USDC liquidity, Morpho share value, and Morpho withdrawal capacity, then determines how much USDC can be served by each venue. Withdrawals are planned against the current pooled allocation. If the pool is 70% Aave and 30% Morpho, a withdrawal initially targets that same proportion. If one venue cannot satisfy its target slice, the router redirects the shortfall to the other venue when capacity is available. If the combined available capacity is insufficient, the withdrawal reverts rather than silently under-delivering. The result: * deposits are routed only through venues that pass safety and amount-capacity checks; * withdrawals use live capacity data rather than assuming both venues are fully liquid; * a single exit request can be served from both venues in one transaction; * one constrained venue can be offset by the other when aggregate liquidity is sufficient; * emergency controls can pause new deposits without blocking withdrawals. Read more: [Withdrawal Flow](/divigent-docs/protocol/withdrawal.md). ## 4-Hour TWAR Routing Yield routing should not chase temporary rate spikes. Divigent uses a 4-hour time-weighted average rate (TWAR) to compare supported venues. The oracle records observations from Aave V3 and Morpho, stores checkpoints in a circular buffer, and computes each venue's time-weighted rate over the observation window. Spot rates can move for reasons that do not represent durable yield: temporary utilisation, single-block conditions, market imbalance, or short-lived vault behaviour. Routing solely on the latest spot rate would make deposits more reactive and easier to distort. The TWAR design favours sustained relative advantage over momentary headline APY. Read more: [Oracle and Routing](/divigent-docs/protocol/oracle-and-routing.md). ## Adaptive Reserve Management Agent wallets need reserve management, not all-in allocation. Divigent's integration model keeps a configurable amount of USDC liquid for near-term activity. Before a payment, the integration can check whether the wallet has sufficient liquid USDC. If liquidity is short, it can withdraw enough from Divigent to cover the payment and preserve the required reserve. After settlement, it can redeploy only the USDC above that reserve floor. This reserve layer is adaptive because the appropriate liquid balance depends on the wallet's operating context: payment size, payment frequency, execution budget, safety buffer, application-specific settlement timing, and operator policy. The smart contracts provide the accounting, receipts, withdrawal previews, and permission model. The SDK and MCP layers use those primitives to help agent applications manage liquidity around payment events. Read more: [Payment Lifecycle](/divigent-docs/quick-start/payment-lifecycle.md). ## The Working-Capital Alternative Without Divigent, teams that want to make idle USDC productive must build and maintain a full capital-management surface: * direct Aave integration; * direct Morpho integration; * venue-selection logic; * rate monitoring; * stale-oracle protection; * deposit and withdrawal accounting; * per-wallet principal tracking; * receipt-token mechanics; * withdrawal-capacity handling; * yield-only fee calculation; * reserve logic around payment flows; * x402 lifecycle integration. That is a protocol-level responsibility, not a minor application feature. Divigent consolidates these requirements into a narrower interface for agent wallets and developers. ## The Divigent Thesis Divigent is not designed to be the broadest yield aggregator. Divigent is designed to be the default yield primitive for agent wallets: the layer between autonomous payment flows and on-chain lending venues, allowing idle USDC to become productive while preserving withdrawal control, transparent accounting, and payment readiness. {% hint style="info" %} Keep operational capital available. Route idle float deliberately. Realise yield without compromising payment readiness. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://divigent.gitbook.io/divigent-docs/getting-started/why-divigent.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.