{"workflow":{"id":"fbeef3d8-748f-4871-871a-eb5aa59c600e","objective":"This launch deploys application contracts only and no token. launch.json is kind evm_contracts, which takes no token, no liquidity pool and no reward distributor, and in which $token does not resolve. The only token involved is the elastic CompToken the vault creates in its own constructor, which is not a launch artifact.\n\nTenth increment on the COMP compute-backed stablecoin, continuing our own repository at the commit in the draft. Everything so far bounds how much COMP can be created. This is the first thing that lets COMP be destroyed at a known price, which is what makes the peg real rather than a unit of account plus a hope that arbitrage closes the gap.\n\nAdd redemption of COMP for the collateral asset IMD, and only that asset. A redeemer names an amount of COMP and a minimum amount of IMD they will accept. The COMP is burned. The IMD comes from the Treasury's reserve FIRST, and only when that is exhausted from the debt of eligible borrower positions. Reserve-first is not an optimisation: both routes improve backing by identical arithmetic, so solvency does not choose, but the Treasury's IMD is idle while a borrower's is working as collateral, and spending the idle asset first means ordinary arbitrage never reaches a position.\n\nA position is eligible only while its collateral ratio is below a ceiling that is DERIVED, not configured: minCR() plus a governed spread, shipping at 50 ratio points. It must be derived because minCR already rises from 150 to 200 as network health falls, so a ceiling pinned at an absolute 200 would collapse the eligible band to nothing exactly during the stress when the peg most needs defending. Anchoring it to minCR scales it with NHI with no second curve. The spread is governed under the existing 48-hour delay, hard-bounded between 25 and 100.\n\nThe ceiling must stay strictly ABOVE minCR: below it a position is already liquidatable, and a liquidator takes the same collateral for the same debt PLUS a bonus, so a redeemer would lose every race for it.\n\nThere is NO sorted list: the caller names a candidate and the contract refuses it unless it is eligible. Nothing can be cherry-picked, because the payout is denominated in the debt repaid rather than the position's ratio. Redemption also RAISES the redeemed position's ratio, since the fee means it gives up less than proportional collateral.\n\nThe fee is a decaying base rate plus a floor, capped. On each redemption the base rate rises by the redeemed fraction of total supply divided by four, and decays with a half-life of about twelve hours. The floor and cap are SOURCE CONSTANTS, not governed parameters: the floor IS the peg, since COMP cannot trade far below one minus the fee without being redeemed, and a governable cap is a redemption halt with extra steps. Floor 50 basis points, cap 500. The divisor of four rather than two is deliberate: at two, redeeming a tenth of supply saturates the cap in one call and the base rate does no work at all.\n\nThe fee is RETAINED AS BACKING and paid to nobody: the redeemer receives one minus the fee and the difference is simply not paid out, so no distribution machinery exists and redemption improves backing strictly more than a fee-free one would.\n\nRedemption must never reach a borrower's collateral except in exchange for retiring their debt. A borrower's IMD is theirs; the protocol may hand it over only against the debt it cancels.\n\nAn independent security review is wanted, weighted on whether a redeemer can be paid twice from one burn, extract more than the fee-adjusted feed price, reach an ineligible position, or leave a position worse off in ratio terms than it began.\n\nYES, this request includes a user-facing website: the single-screen terminal gains a redemption pane, described in the step objective.","status":"completed","brief":"# Approved workflow\n\nThis launch deploys application contracts only and no token. launch.json is kind evm_contracts, which takes no token, no liquidity pool and no reward distributor, and in which $token does not resolve. The only token involved is the elastic CompToken the vault creates in its own constructor, which is not a launch artifact.\n\nTenth increment on the COMP compute-backed stablecoin, continuing our own repository at the commit in the draft. Everything so far bounds how much COMP can be created. This is the first thing that lets COMP be destroyed at a known price, which is what makes the peg real rather than a unit of account plus a hope that arbitrage closes the gap.\n\nAdd redemption of COMP for the collateral asset IMD, and only that asset. A redeemer names an amount of COMP and a minimum amount of IMD they will accept. The COMP is burned. The IMD comes from the Treasury's reserve FIRST, and only when that is exhausted from the debt of eligible borrower positions. Reserve-first is not an optimisation: both routes improve backing by identical arithmetic, so solvency does not choose, but the Treasury's IMD is idle while a borrower's is working as collateral, and spending the idle asset first means ordinary arbitrage never reaches a position.\n\nA position is eligible only while its collateral ratio is below a ceiling that is DERIVED, not configured: minCR() plus a governed spread, shipping at 50 ratio points. It must be derived because minCR already rises from 150 to 200 as network health falls, so a ceiling pinned at an absolute 200 would collapse the eligible band to nothing exactly during the stress when the peg most needs defending. Anchoring it to minCR scales it with NHI with no second curve. The spread is governed under the existing 48-hour delay, hard-bounded between 25 and 100.\n\nThe ceiling must stay strictly ABOVE minCR: below it a position is already liquidatable, and a liquidator takes the same collateral for the same debt PLUS a bonus, so a redeemer would lose every race for it.\n\nThere is NO sorted list: the caller names a candidate and the contract refuses it unless it is eligible. Nothing can be cherry-picked, because the payout is denominated in the debt repaid rather than the position's ratio. Redemption also RAISES the redeemed position's ratio, since the fee means it gives up less than proportional collateral.\n\nThe fee is a decaying base rate plus a floor, capped. On each redemption the base rate rises by the redeemed fraction of total supply divided by four, and decays with a half-life of about twelve hours. The floor and cap are SOURCE CONSTANTS, not governed parameters: the floor IS the peg, since COMP cannot trade far below one minus the fee without being redeemed, and a governable cap is a redemption halt with extra steps. Floor 50 basis points, cap 500. The divisor of four rather than two is deliberate: at two, redeeming a tenth of supply saturates the cap in one call and the base rate does no work at all.\n\nThe fee is RETAINED AS BACKING and paid to nobody: the redeemer receives one minus the fee and the difference is simply not paid out, so no distribution machinery exists and redemption improves backing strictly more than a fee-free one would.\n\nRedemption must never reach a borrower's collateral except in exchange for retiring their debt. A borrower's IMD is theirs; the protocol may hand it over only against the debt it cancels.\n\nAn independent security review is wanted, weighted on whether a redeemer can be paid twice from one burn, extract more than the fee-adjusted feed price, reach an ineligible position, or leave a position worse off in ratio terms than it began.\n\nYES, this request includes a user-facing website: the single-screen terminal gains a redemption pane, described in the step objective.\n\nContinues our own repository at the commit in the draft, which MUST be repinned to the commit the previous increment pushes. docs/COMPUTE-BACKING-DESIGN.md section 5 is the design and the reference for every number here; this is item 4 of its build order, and only item 4.\n\nTWO EXISTING PROPERTIES MUST SURVIVE; neither is new work. Redemption shrinks both terms of workCeiling, so COMP below peg tightens work-minting with no governance and no oracle. And work-minted COMP has no position behind it, so redeeming it consumes borrowers' collateral - the dilution the work ceiling bounds.\n\nlaunch.json is already the evm_contracts kind and names PriceFeed, NhiFeed, SpotFeed and ParameterizedVault. The manifest cap is eight but a request can declare only four, so four is the binding number. A manifest makes no post-deploy calls and cannot name one artifact twice. Redemption is therefore VAULT METHODS, not a new contract: it burns COMP, reads positions and moves collateral, all of which the vault already does. The cap is eight, so there is room, but do not spend it - Treasury, UsdPriceFeed, Parameters and CompToken are created in the vault's constructor so the deployment comes up linked with nothing sent afterwards.\n\nThe manifest passes zero for the work-oracle argument, which is the grantRights faucet, and that must not change: the attested SwarmWorkOracle needs a WorkOracleFactory already deployed and named in src/DeploymentConfig.sol, and that factory is not on chain yet.\n\nAuthority is never a constructor argument here. The feeds take only (maxAge_, maxDeviationBps_); attester, relayer, reporters, quorum, answerType and payload chainId are constants in src/DeploymentConfig.sol, because a manifest once substituted its own values and both feeds were permanently inert. Do not reintroduce them, and do not pass a literal address for anything a constructor validates - a literal has code only on the chain it was deployed to, which made an earlier manifest unconstructible elsewhere.\n\nfoundry.toml sets isolate = true and test/README.md documents plain `forge test`. Keep both working: backedDebt's snapshot reads transaction boundaries, which a non-isolated run collapses.\n\nDo not touch SwarmFeed.questionPolicy, _requireQuestion, expectedQuestionHash or any existing QUESTION_PREFIX: those constants are generated from the payloads in oracle/ and all four feeds depend on them.\n\nforge build compiles script/ as well as src/ and test/, so a vault change must be matched in all three scripts under script/ in the same step as the change.\n\nOut of scope, each its own later increment: redemption channel B, which prices a free choice among reserve assets by how far each sits below a target basket weight - those weights are not decided; the stability fee's burn-and-convert split; any change to what denominates a collateral ratio; and any change to existing parameter values, their bounds, the 48-hour delay or the governor.\n\nSepolia only (11155111).\n\nAdd redemption of COMP for IMD: reserve first, then eligible positions below a ceiling derived from minCR, priced by a capped decaying fee whose floor and cap are source constants.\n","briefDigest":"e49f72ff924ba7f81296985f762a42bd12e050ad2eb7b8c7f505e8ea4e90e3f1"},"planning":null,"id":"a7f40133-ae45-4ec3-a753-984ebe815525","state":"completed","template":"shape:dag","objective":"WORKFLOW CONTRACT STAGE CONTEXT: the stage produces implemented and tested contracts, ABI documentation and an independently reviewed launch.json. Each assignment contributes only within its own role and write scope. Source-producing assignments own implementation, tests and ABI exports at docs/abi/<Contract>.json where their scope permits. The generated manifest assignment writes only launch.json. Review assignments inspect accepted source and manifest and return findings without editing files; they do not implement contracts or generate ABI files. Use the supplied canonical manifest guidance: policy and signed artifact linkage belong to services, while concrete source, constructor, policy or authorization conflicts remain review findings. Services publish source, attest, admit and deploy after this stage, then start the frontend. Read .imd/reads/workflow.md for the complete approved requirements and apply them to your assigned contribution; later service outcomes are not prerequisites of this assignment.","blockedReason":null,"createdAt":"2026-10-04T03:42:05.277Z","updatedAt":"2026-10-04T08:50:37.232Z","paidBy":"0x5167d014a056e43883e1bbea5530c3c0dc993281","parentJobId":null,"project":{"id":"a7f40133-ae45-4ec3-a753-984ebe815525","head":"f5d514dd-cb61-4582-8f53-49ea56b3eaba","running":null,"versions":[{"jobId":"a7f40133-ae45-4ec3-a753-984ebe815525","workflowId":"fbeef3d8-748f-4871-871a-eb5aa59c600e","objective":"This launch deploys application contracts only and no token. launch.json is kind evm_contracts, which takes no token, no liquidity pool and no reward distributor, and in which $token does not resolve. The only token involved is the elastic CompToken the vault creates in its own constructor, which is not a launch artifact.\n\nTenth increment on the COMP compute-backed stablecoin, continuing our own repository at the commit in the draft. Everything so far bounds how much COMP can be created. This is the first thing that lets COMP be destroyed at a known price, which is what makes the peg real rather than a unit of account plus a hope that arbitrage closes the gap.\n\nAdd redemption of COMP for the collateral asset IMD, and only that asset. A redeemer names an amount of COMP and a minimum amount of IMD they will accept. The COMP is burned. The IMD comes from the Treasury's reserve FIRST, and only when that is exhausted from the debt of eligible borrower positions. Reserve-first is not an optimisation: both routes improve backing by identical arithmetic, so solvency does not choose, but the Treasury's IMD is idle while a borrower's is working as collateral, and spending the idle asset first means ordinary arbitrage never reaches a position.\n\nA position is eligible only while its collateral ratio is below a ceiling that is DERIVED, not configured: minCR() plus a governed spread, shipping at 50 ratio points. It must be derived because minCR already rises from 150 to 200 as network health falls, so a ceiling pinned at an absolute 200 would collapse the eligible band to nothing exactly during the stress when the peg most needs defending. Anchoring it to minCR scales it with NHI with no second curve. The spread is governed under the existing 48-hour delay, hard-bounded between 25 and 100.\n\nThe ceiling must stay strictly ABOVE minCR: below it a position is already liquidatable, and a liquidator takes the same collateral for the same debt PLUS a bonus, so a redeemer would lose every race for it.\n\nThere is NO sorted list: the caller names a candidate and the contract refuses it unless it is eligible. Nothing can be cherry-picked, because the payout is denominated in the debt repaid rather than the position's ratio. Redemption also RAISES the redeemed position's ratio, since the fee means it gives up less than proportional collateral.\n\nThe fee is a decaying base rate plus a floor, capped. On each redemption the base rate rises by the redeemed fraction of total supply divided by four, and decays with a half-life of about twelve hours. The floor and cap are SOURCE CONSTANTS, not governed parameters: the floor IS the peg, since COMP cannot trade far below one minus the fee without being redeemed, and a governable cap is a redemption halt with extra steps. Floor 50 basis points, cap 500. The divisor of four rather than two is deliberate: at two, redeeming a tenth of supply saturates the cap in one call and the base rate does no work at all.\n\nThe fee is RETAINED AS BACKING and paid to nobody: the redeemer receives one minus the fee and the difference is simply not paid out, so no distribution machinery exists and redemption improves backing strictly more than a fee-free one would.\n\nRedemption must never reach a borrower's collateral except in exchange for retiring their debt. A borrower's IMD is theirs; the protocol may hand it over only against the debt it cancels.\n\nAn independent security review is wanted, weighted on whether a redeemer can be paid twice from one burn, extract more than the fee-adjusted feed price, reach an ineligible position, or leave a position worse off in ratio terms than it began.\n\nYES, this request includes a user-facing website: the single-screen terminal gains a redemption pane, described in the step objective.","baseCommit":"5cc5745ea2ddf1585e3b250676027fd4fa965c32","state":"completed","createdAt":"2026-10-04T03:42:05.277Z"}]},"deliver":true,"host":false,"site":null,"launch":{"requested":true,"kind":"evm_contracts","id":"83f17459-20df-43c3-846b-7e4187fe21ab","status":"live","chainId":11155111},"oracleRequestId":null,"delivery":{"repoUrl":"https://github.com/identity-md-launches/launch-688-pricefeed-nhifeed-spotfeed-parameterized","pullRequestUrl":"https://github.com/identity-md-launches/launch-688-pricefeed-nhifeed-spotfeed-parameterized/pull/1","commit":"6c08b0fc122bc0e02016cf9c4f507e2dfaadfcc3","deliveredAt":"2026-10-04T08:50:43.058Z","media":null},"media":null,"nodes":[{"key":"audit_economics","role":"review","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":["contracts","tests","manifest"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-04T05:19:10.950Z","verdict":null,"seat":{"tokenId":"6","agentId":"51018"},"live":null},{"key":"audit_flow","role":"review","state":"accepted","attempt":3,"revisions":0,"judgeRevisions":0,"dependsOn":["contracts","tests","manifest"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-04T05:20:38.120Z","verdict":null,"seat":{"tokenId":"1473","agentId":"51481"},"live":null},{"key":"audit_judge","role":"review","state":"accepted","attempt":1,"revisions":2,"judgeRevisions":2,"dependsOn":["contracts","tests","manifest","audit_math","audit_permissions","audit_economics","audit_flow"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-04T08:50:37.232Z","verdict":null,"seat":{"tokenId":"1871","agentId":"51032"},"live":null},{"key":"audit_math","role":"review","state":"accepted","attempt":2,"revisions":0,"judgeRevisions":0,"dependsOn":["contracts","tests","manifest"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-04T05:14:58.204Z","verdict":null,"seat":{"tokenId":"351","agentId":"51023"},"live":null},{"key":"audit_permissions","role":"review","state":"accepted","attempt":2,"revisions":0,"judgeRevisions":0,"dependsOn":["contracts","tests","manifest"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-04T05:17:27.117Z","verdict":null,"seat":{"tokenId":"13","agentId":"51504"},"live":null},{"key":"contracts","role":"implement","state":"accepted","attempt":1,"revisions":4,"judgeRevisions":2,"dependsOn":[],"allowedPaths":["src","src/**","docs","docs/**","script","script/**"],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-04T08:16:41.220Z","verdict":{"status":"accepted","profile":"foundry","evaluation":"checks","rejectionCode":null,"detail":"all checks passed","verifierVersion":"0.1.0+8df7996c","verifiedTreeHash":"5f49d87e008b50fab1bdd3073295f9d3469166ff","at":"2026-10-04T08:16:41.220Z","failedChecks":[]},"seat":{"tokenId":"6","agentId":"51018"},"live":null},{"key":"manifest","role":"integrate","state":"accepted","attempt":1,"revisions":2,"judgeRevisions":2,"dependsOn":["contracts","tests"],"allowedPaths":["launch.json"],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-04T08:39:22.943Z","verdict":{"status":"accepted","profile":"foundry","evaluation":"checks","rejectionCode":null,"detail":"all checks passed","verifierVersion":"0.1.0+8df7996c","verifiedTreeHash":"2a11054afc3bb5e5f46b44b3ea01d677d0623810","at":"2026-10-04T08:39:22.943Z","failedChecks":[]},"seat":{"tokenId":"420","agentId":"50939"},"live":null},{"key":"tests","role":"tests","state":"accepted","attempt":1,"revisions":4,"judgeRevisions":2,"dependsOn":["contracts"],"allowedPaths":["test","test/**"],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-04T08:29:39.772Z","verdict":{"status":"accepted","profile":"foundry","evaluation":"checks","rejectionCode":null,"detail":"all checks passed","verifierVersion":"0.1.0+8df7996c","verifiedTreeHash":"2ca58e3e94c80eef0f7590676913583a86ba790d","at":"2026-10-04T08:29:39.773Z","failedChecks":[]},"seat":{"tokenId":"6","agentId":"51018"},"live":null}],"reviews":[{"status":"sent","chainId":1,"txHash":"0xa7325cdfa0ec3f067a1dd7fdbca6137a43d1a6744a5f6f321662cdd945b2018d","blockNumber":26121538,"sentAt":"2026-10-04T20:59:49.365Z","entries":[]},{"status":"sent","chainId":1,"txHash":"0xdce95e931e65bab3b5fce6eb4ed47fe0d27a8714d826b7f6914452d3cd6965ae","blockNumber":26119162,"sentAt":"2026-10-04T13:03:04.751Z","entries":[]},{"status":"sent","chainId":1,"txHash":"0x3c480e5314562988f75e475c2387439444df64c386cbdf65d542502d74e1cd02","blockNumber":26117906,"sentAt":"2026-10-04T08:51:05.126Z","entries":[{"nodeKey":"audit_economics","agentId":"51018","value":1,"role":"review:submission"},{"nodeKey":"audit_flow","agentId":"51481","value":1,"role":"review:submission"},{"nodeKey":"audit_judge","agentId":"51032","value":1,"role":"review:submission"},{"nodeKey":"audit_math","agentId":"51023","value":1,"role":"review:submission"},{"nodeKey":"audit_permissions","agentId":"51504","value":1,"role":"review:submission"},{"nodeKey":"contracts","agentId":"50957","value":1,"role":"verification:checks"},{"nodeKey":"contracts","agentId":"51018","value":1,"role":"verification:checks"},{"nodeKey":"manifest","agentId":"50957","value":1,"role":"verification:checks"},{"nodeKey":"manifest","agentId":"51018","value":1,"role":"verification:checks"},{"nodeKey":"manifest","agentId":"50939","value":1,"role":"verification:checks"},{"nodeKey":"tests","agentId":"50957","value":0,"role":"verification:checks"},{"nodeKey":"tests","agentId":"51018","value":1,"role":"verification:checks"},{"nodeKey":"tests","agentId":"50971","value":1,"role":"verification:checks"}]}]}