Agentic Lending EVK

This skill turns the repo's current planner primitives into one agent-facing workflow, from feed readiness through deployment and live borrow proof.

Safety expectations

• default to planning, simulation, or preview mode first
• treat browser-assisted funding as optional and only automate it when the user wants the flow completed end to end
• only use live signer-backed funding, deployment, or borrow canaries when the user explicitly asks for live execution
• for the bundled borrow-proof script, require both --live and config.liveAcknowledgement === "I_UNDERSTAND_THIS_WILL_SEND_TRANSACTIONS"
• require the configured proof account address to match the signer address before any live proof transaction is sent
• keep private key material in environment variables or local runtime config, never in committed files

Use this when

• the user wants to stand up or dry-run an EVK lending market backed by Api3 feeds
• the user wants one workflow instead of manually stitching planner JSON steps
• the task includes any combination of asset selection, feed readiness, feed funding, oracle preparation, EVK deployment prep, guarded dry-run or send, or post-deploy borrow proof

Do not use this when

• the user wants Morpho, not EVK
• the requested recipe or oracle path is not supported by the current repo
• the task requires pretending a skeleton-only path is executable
• the task assumes fully autonomous feed funding in every case

Read next

1. references/api_reference.md
2. references/current_capabilities.md
3. references/live-borrow-checklist.md when the workflow reaches post-deploy proof
4. references/arbitrum-eusdc1-isolated-example.json when a concrete proof config shape helps
5. Run node scripts/evk_live_borrow_proof.js --help for the bundled proof executor

Minimum required inputs for the combined flow

Gather these before you assume the full combined workflow is feasible:

• chain name and chain id
• collateral asset set and borrow asset set
• target recipe id or risk preset
• whether the user wants planning only, dry-run, or real send
• whether the user also wants post-deploy borrow proof
• live RPC availability for the chain
• signer expectations for any live funding, deployment, or proof step
• vaultContext when the deployment path needs concrete factory or asset wiring

For a full live end-to-end run, also confirm:

• feed funding branch expectations, especially whether fundingExecutionClassification.state may be browser-assisted
• browser access if the Api3 Market flow must be automated
• a safe tiny borrow amount for the proof step
• a target collateral vault for the proof, not just the borrow vault

If any of those are missing, stop and ask instead of improvising.

Default workflow

1. Normalize the request into:
   • chain
   • collateral assets
   • borrow assets
   • target recipe or risk preset
   • whether the user wants planning only, dry-run, or real send
   • whether the user also wants proof of actual borrowability
2. Prefer run-evk-workflow as the default end-to-end entrypoint when the user wants the full EVK path.
   • pass recipeId explicitly when known, otherwise let the runner infer from the current EVK recipe catalog
   • treat status as the canonical summary object
   • treat result as the detailed staged artifact bundle
3. If deployment succeeds and the user wants proof of actual borrowability, continue within this skill to the built-in post-deploy proof step.
   • treat deployment success and borrowability proof as separate milestones
   • use the deployment outputs plus live vault addresses, collateral-vault targets, EVC state, and tiny borrow sizing to build the proof config
   • require preview mode first, then live canary only if the user wants a real proof
4. Fall back to the manual staged commands only when the user asked for a subset, wants intervention at a specific phase, or the runner stops before the desired outcome.
   • plan-market
   • ensure-feeds
   • if feeds are live, continue to the oracle and EVK planner path
   • if funding is needed, inspect purchase-inputs or prepare-buy-subscription output and branch on fundingExecutionClassification.state
   • if fundingExecutionClassification.state === "executable":
     • purchase-inputs
     • prepare-contract-call or prepare-buy-subscription
     • execute-buy-subscription
     • ensure-feeds or ensure-active again to confirm the feed is now live
   • if fundingExecutionClassification.state === "browser-assisted":
     • call browser-plan
     • use the browser tool to execute the returned plan if the required UI is reachable and the user wants full automation
     • re-run ensure-feeds or ensure-active after the browser flow
   • if fundingExecutionClassification.state === "unsupported", stop and report unsupported status clearly
   • prepare-euler-oracle
   • prepare-evk-market
   • prepare-evk-deployment
   • deploy-evk-market
   • scripts/evk_live_borrow_proof.js for the post-deploy proof step when requested
5. Stop and report honestly if:
   • feed funding is unsupported
   • the browser-assisted funding UI is not reachable or cannot be automated safely
   • the oracle path is still skeleton-only
   • the EVK market path is still skeleton-only
6. Prefer dry-run first for exact onchain funding and deployment paths.
7. For browser-assisted funding, prefer browser automation over asking the user to click through manually when the UI is reachable.
8. Only use real send when the user explicitly wants it and the guarded acknowledgement contract is present.
9. Do not claim a market is borrowable just because deployment succeeded. A live or at least previewed post-deploy proof step is required for that claim.

Built-in post-deploy borrow proof

Use scripts/evk_live_borrow_proof.js.

It supports:

• preview mode with a read-only account address
• live mode with a signer loaded from an environment variable
• optional debt repayment before the new proof
• optional single-hop Uniswap V3 style swaps to source repay or collateral assets
• collateral deposit into the target EVK vault
• disabling stale collateral vaults in EVC
• disabling stale controllers in EVC
• enabling the target collateral and optionally the target controller
• final tiny borrow and before or after logging

Keep the proof honest:

• distinguish mixed-collateral borrow from isolated target-collateral borrow
• preserve the exact funding branch that led here
• verify quoteability, LTV wiring, EVC state, and vault cash before a live canary
• if the chain does not use a Uniswap V3 compatible router, replace or bypass the bundled swap step explicitly

Current happy-path rule

The currently supported end-to-end EVK path requires:

• feeds that are already live, or a feed that can be activated through the current narrow exact buySubscription(...) path
• an oracle path that already resolves to executable oracle transactions
• top-level prepare-evk-deployment.vaultContext
  • factoryAddress
  • assetAddress
• guarded send fields on the funding and deployment executor requests

Without that vaultContext, the first EVK market transaction remains skeleton-only and readyToBroadcast must stay false. Without a supported exact buy-subscription path, feed funding must stay at handoff or prep only.

Output expectations

When using this skill, always report:

• status.phaseReached when the top-level runner is used
• status.state when the top-level runner is used
• status.recipeId when the top-level runner is used
• what is executable vs still skeleton-only
• blockers and warnings
• fundingExecutionClassification.state when feed funding is involved manually
• status.fundingExecutionState when the top-level runner is used
• whether the current state is:
  • plan-only
  • feed-ready but awaiting activation or funding handoff
  • funding dry-run ready
  • browser-assisted funding ready
  • oracle-executable
  • EVK dry-run ready
  • real-send ready
  • deployed but borrow-proof pending
  • live borrow proven

If the user asked for borrowability proof, also report whether the workflow has already reached the post-deploy proof step or is still waiting on proof inputs.

If the top-level runner is used, also surface the executable flags under status.executable instead of paraphrasing them away.

Tone

Be blunt about current limits. Do not overclaim generalized support. Do not blur deployment success into borrowability proof. If the workflow falls off the happy path, say exactly where and why.