{"assessments":[],"deployments":[],"fuzz":[],"identity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"interpretation":"Records acceptance and evidence. Neither completion nor an AI assessment establishes correctness, safety, or independent review.","jobId":"297985f3-f677-4911-89c9-a646e2003aff","kind":"skill:research-report","nodes":[{"acceptedSubmissionHash":"1c72a185198f1d3b9fbfc012cf304a9ef17bf7899f29efaf8b305cd2483721f8","dependsOn":[],"execution":{"network":true,"profile":"none","requires":["network"],"skillHash":"3ddca93330036359dd721585e58e67820336a0398b7927b3c89369d6134f30f6","skillId":"research-report","tools":[]},"key":"research_report","kind":"code","role":"implement","skillHash":"3ddca93330036359dd721585e58e67820336a0398b7927b3c89369d6134f30f6","skillId":"research-report","state":"accepted"}],"objective":"Recommend risk parameters for a USD-denominated CDP stablecoin whose only collateral is a volatile, thin-liquidity token, and whose price oracle updates on demand rather than on a heartbeat. Report what comparable live protocols actually use, with sources, and say where our current values are wrong and in which direction.\n\nTHE SYSTEM, so the answer is not generic.\n\nCollateral: sIMD, an ERC-4626 share wrapper (24 decimals) over IMD (18 decimals). The vault holds about 1,752,000 IMD, roughly 14.9M USD. IMD trades in a single Uniswap v4 pool; the older v3 pool is drained, so that pool is the whole market. IMD is near 8.50 USD and moved +44.6% in about one day on 2026-10-02. The share price is monotone, roughly 0.027%/day of yield.\n\nDebt: a stablecoin minted against that collateral, denominated in USD by multiplying the IMD/ETH oracle by Chainlink ETH/USD.\n\nOracle: a swarm panel signs an attestation that a contract verifies. Each update costs about 4.25 USD and is bought ON DEMAND; there is no heartbeat and no keeper network pushing prices. A feed refuses a new value that moves more than a deviation cap from its current one, so catching up on a large move takes several successive paid updates, each of which must land inside the cap at the time. We have already had one request refused by the panel because the market left the answerable band between paying and answering.\n\nOUR CURRENT VALUES, all of which you should challenge:\n- Minimum collateral ratio 150%, rising to 200% as a protocol-health index falls.\n- Liquidation bonus 10% of the debt repaid. Of that bonus, 10% goes to whoever first flagged the position and 33.33% to the protocol; the liquidator keeps the rest.\n- Grace period 6 hours before a flagged position can be liquidated, falling to 0 under stress.\n- Oracle deviation cap 20% per update on the primary feed; a separate 5% bound between the primary feed and a spot reading, outside which the vault halts.\n- Price staleness limit 24 hours; 1 hour for the spot feed.\n- Stability fee 200 bps per year.\n- Redemption: a fee with a 50 bps floor and a 500 bps cap, where the base rate rises by (amount redeemed / supply / 4) per redemption and decays with a 12 hour half life.\n\nWHAT TO ANSWER, each separately and with figures.\n\n1. Is a 10% liquidation bonus enough to attract liquidators for collateral that can move 44% in a day, given the liquidator must hold stablecoin inventory and sell the seized token into one pool? Say what bonus comparable protocols use for their most volatile or longest-tail collateral, and what ours should be.\n\n2. Is 150% a defensible minimum collateral ratio for this collateral and this pool depth? Give the reasoning a protocol would use to set it, and the number it produces here.\n\n3. Taking 33.33% of the liquidation bonus for the protocol: does a cut that size measurably reduce liquidation participation? Name protocols that take a cut and say how much.\n\n4. The deviation cap and the update cadence are one knob: a cap smaller than the market's move between updates means the feed can never catch up, and a larger one weakens the only bound on a bad attestation. How do protocols with slow, expensive or on-demand oracles set this, and what should a protocol do when a single move exceeds the cap? Address whether the cap should widen as the feed goes stale.\n\n5. Is 200 bps a reasonable stability fee here, and is our redemption fee shape right? Compare the floor, the cap, the increase per redemption and the decay half life against the live protocols that use this design, and say whether a divisor of 4 rather than 2 is defensible.\n\nPrefer protocols with public parameters and post-mortems: name them, give the figure, and cite where it is set. Where a parameter was changed after a loss, say what the loss was. Separate what is standard practice from what is one protocol's choice. If a parameter of ours is dangerous rather than merely suboptimal, say so first.\n\nTHE REPORT MUST CONTAIN, and will be read for each of these:\n- a recommended figure for each of the five numbered questions, with the reasoning that produced it\n- named live protocols with their actual parameter values and a citation for each value\n- minimum collateral ratios and liquidation bonuses used for volatile or long-tail collateral, by protocol\n- at least two protocols that take a protocol cut of the liquidation bonus, with the size of the cut\n- how protocols with slow, expensive or on-demand oracles set a per-update deviation bound\n- an explicit statement of which of our current values is most dangerous and why\n- where a parameter was changed after a loss, what the loss was\n\nAND MUST NOT REST ON:\n- a single protocol's documentation\n- generic DeFi risk commentary with no named protocol or figure\n- marketing or launch announcements\n\nCite at least ten distinct sources, each a page that states the figure it is cited for.","parentJobId":null,"planHash":"1011b86a41c93fd82152abd1f4fa7396d3d1b98c3cec2c49eb4740916c38f91b","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"297985f3-f677-4911-89c9-a646e2003aff","publication":{"commit":null,"deliveredAt":null,"repoUrl":null},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[{"agentId":"51199","feedbackHash":"612c8791d46a61216dddbcda90afb381bfc6b0087fd4ad0b75f5568a9489fd89","nodeKey":"research_report","submissionHash":"1c72a185198f1d3b9fbfc012cf304a9ef17bf7899f29efaf8b305cd2483721f8","tag1":"verification:structural","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"6556f8927e58fe28576a468c444e9903c0392dd8db34f92ac5e5aa1056c4ad4e","state":"completed","submissions":[{"artifacts":[{"bytes":34405,"hash":"00dc5a26eee35860863b0bec0e11a391e7fc9e4d3425ad49654eddab5acada57","mediaType":"text/markdown","name":"report","path":"artifacts/report.md"}],"attempt":1,"bundleHash":null,"device":"4fcac33561ba733d","findings":[],"hash":"1c72a185198f1d3b9fbfc012cf304a9ef17bf7899f29efaf8b305cd2483721f8","nodeId":"1dd25159-cfbe-488c-8a65-144a97d9ec88","outcome":"completed","summary":"Created [artifacts/report.md](artifacts/report.md), with sourced protocol comparisons, recommendations for all five questions, loss reviews, and explicit uncertainties. Includes a README and three on-chain parameter snapshots.\n\nThe principal danger is **24-hour price staleness combined with six-hour liquidation grace**. Recommended starting values include **300% MCR**, **20% gross liquidation bonus**, and **zero initial protocol cut**, conditional on liquidity testing.\n\nArithmetic and output checks passed. Files remain untracked.","treeHash":"4b825dc642cb6eb9a060e54bf8d69288fbee4904","usage":{"cachedInputTokens":1298048,"inputTokens":86307,"model":"gpt-6.1-sol","outputTokens":19789,"runtime":"codex","turns":6,"wallClockMs":744958}}],"verification":[{"checks":[],"detail":"paths and tree verified; no suite was run for this kind of work","evaluation":"structural","profile":"none","status":"accepted","submissionHash":"1c72a185198f1d3b9fbfc012cf304a9ef17bf7899f29efaf8b305cd2483721f8","verifiedTreeHash":"4b825dc642cb6eb9a060e54bf8d69288fbee4904","verifierVersion":"0.1.0+bb1c0c94"}]}