Agentic Lending EVK#

This is the execution-capable EVK workflow skill.

It turns the bundled EVK planner primitives into one agent-facing workflow, from route resolution and feed readiness through deployment and live borrow proof.

When the supported path is available and the user explicitly asks for it, this variant can send real transactions and should be treated as a guarded execution skill rather than a planning-only helper.

Golden path for normal use#

Use one request file and one wrapper command. Do not drop into lower-level commands unless debugging, intervention, or proof-specific follow-up is required.

1. Create request.json with exact collateralAssets, exact borrowAssets, chain, risk intent, feed-funding intent, and EVK deployment intent.

   • For a live-shaped starting point, copy references/live-request-template.json and replace every placeholder before use.

2. Preflight before any live-capable EVK execution:

   agentic-lending-evk preflight-evk-workflow --input-file ./request.json --format json

   Stop unless safeToRun === true.

3. Run:

   agentic-lending-evk run-evk-workflow --input-file ./request.json --format json

4. If the run was persisted, inspect or recover it with:

   • agentic-lending-evk explain-next --run-dir <run-dir> --format json
   • agentic-lending-evk verify-evk-deployment-handoff --run-dir <run-dir> --format json
   • agentic-lending-evk run-evk-workflow --resume-from-run-dir <run-dir> --input-file <run-dir>/request.json --format json

5. If the user asked for borrowability proof, continue with the bundled proof executor only after the deployment bundle is reviewed.

6. Report full deployment success only from persisted artifacts and exact status fields, not from narrative text.

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 the config's guarded live-send acknowledgement field to match the script's required phrase
• require the configured proof account address to match the signer address before any live proof transaction is sent
• require explicit nonzero swap protection for every live swap
• require explicit opt-in before using unlimited approvals
• 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, oracle route resolution, 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/summary-contract.md before claiming deployment success from wrapper output
4. references/live-borrow-checklist.md when the workflow reaches post-deploy proof
5. references/arbitrum-eusdc1-isolated-example.json when a concrete proof config shape helps
6. Use the bundled executor at scripts/evk_live_borrow_proof.js
7. Treat bundled data/part2/feed-status.json and data/part2/market-registry.json as packaged local snapshots, not authoritative shared state

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. Resolve the oracle path for the selected assets before treating deployment as executable.

   • prefer an exact direct route when the requested pair exists and is deployable
   • otherwise use a supported composed route when the planner can prove it cleanly
   • prefer literal exact feed-name matches before alias-normalized fallback matches

3. Prefer preflight-evk-workflow, then run-evk-workflow, as the default end-to-end entrypoints when the user wants the full EVK path.

   • preflight-evk-workflow is the live-safety gate for placeholder detection, preview status, and blocker surfacing
   • 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
   • enable artifacts.enabled whenever the run may need review, handoff, or a durable success claim
   • after a persisted run, prefer agent-decision.json, summary.json, and rollback-plan.json over ad-hoc interpretation
   • use explain-next for operator guidance, verify-evk-deployment-handoff for deployment-complete handoff checks, and --resume-from-run-dir when continuing a known run

4. 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

5. 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

   • the bundled scripts/evk_live_borrow_proof.js executor for the post-deploy proof step when requested

6. 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

7. Prefer dry-run first for exact onchain funding and deployment paths.

8. For browser-assisted funding, prefer browser automation over asking the user to click through manually when the UI is reachable.

9. Only use real send when the user explicitly wants it and the guarded acknowledgement contract is present.

10. Keep the path generic across supported pairs.

• do not special-case only previously tested collateral/borrow combinations
• use the same resolution, funding, deployment, and proof rules for whichever supported assets are selected

1. 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#

Treat the published skill as a complete artifact: it includes the proof executor it tells the agent to run.

Bundled executor path:

• scripts/evk_live_borrow_proof.js

Bundled planner data path:

• data/part2/

Use the bundled planner data as the local default input set for this published skill. If the operator supplies fresher live RPC results or explicit --registry-file / --feed-status-file overrides, prefer those fresher inputs instead of pretending the packaged snapshots are always current.

Before a live-capable run, enable artifact persistence so the deployment and proof handoff do not depend on memory alone:

json

{
  "artifacts": {
    "enabled": true,
    "label": "evk-live-run"
  }
}

Handoff contract:

1. generate borrow-proof-config.json
2. verify the bundled executor path exists in the installed skill
3. run preview first with node ./scripts/evk_live_borrow_proof.js --config <path>
4. rerun with --live only when the user explicitly wants the canary

The bundled executor 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
• require nonzero amountOutMinimum for live swaps
• keep approval scope exact unless the operator explicitly opts into approvalPolicy.mode = "unlimited"

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
• a cleanly resolved oracle path for the selected assets
• 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:

• whether preflight-evk-workflow.safeToRun passed before any live-capable request
• 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
• result.artifactPersistence.bundleDir when artifacts were enabled
• 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.

Do not claim final deployment success unless the wrapper artifacts support it. Read references/summary-contract.md and require at minimum:

• persisted status.json and response.json
• persisted summary.json, agent-decision.json, and rollback-plan.json
• status.state === "real-send ready" only for readiness, not success
• deploy-evk-market.json showing the intended deploy plan or live send result
• verify-evk-deployment-handoff passing when the run is being handed off as deployment-complete
• a separate proof status when borrowability was requested

Tone#

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