Promote the casing builds to default, retire the preview track - #244
Open
Unisay wants to merge 3 commits into
Open
Promote the casing builds to default, retire the preview track#244Unisay wants to merge 3 commits into
Unisay wants to merge 3 commits into
Conversation
… track The van Rossem hard fork activated on mainnet on 2026-07-18 (protocol version 11), making builtin casing and the batch-6 builtins production features, and plutus-tx-plugin 1.67 removed the datatypes=BuiltinCasing option outright. The preview track had nothing left to preview. All 30 _preview submissions move onto the production track: min_plutus_version dropped, the BuiltinCasing / vanRossem entries dropped from flags, prose reframed, and each directory renamed onto the non-casing sibling it was compiled from, which is then retired. Nothing declares min_plutus_version any more and no _preview directory remains, so `cape submission measure --preview` reports no submissions. That is the correct steady state until something targets protocol version 12; the preview machinery stays in place, re-aimed at 1.67. Each casing build replaces the sibling it was actually built from, decided per submission by source pin rather than assuming it is always `default`. For 27 of 30 that is `default`, and the headline number improves by 13-32%. The three Plinth 1.64 exceptions (htlc, linear_vesting, two_party_escrow) share a source commit with the _plain or _asdata variant, having been built before the monadic decoder landed for that line: promoting them onto `default` would have swapped in artifacts 111-153% more expensive and shown a regression at 1.64 that reflects a source revision, not a compiler feature. They replace _plain / _asdata instead, where they win by 7.7%, 28.1% and 31.3%, leaving the monadic default for that line untouched. 73 submissions, all measured on PlutusTx.Eval-1.63.0.0, all verified. The evolution report now shows four mainnet columns for both Plinth and Scalus and no preview teaser; the Plinth timeline gains a 1.61 point that was previously preview-only. ADR 20260526 gains Refinement 4 recording the promotion, and its two claims that a CAPE_CURRENT_PLUTUS_VERSION bump would re-derive the classification for free are marked as superseded. Refinement 2 had already moved report routing to the directory-name suffix, which is what made this a migration rather than a no-op. Closes #242
Contributor
🚀 PR Preview DeployedPreview URL: https://intersectmbo.github.io/UPLC-CAPE/pr-244/ The preview site is automatically updated on every push to this PR and will be removed when the PR is closed. |
Promotion dropped min_plutus_version from all 30 casing submissions, which threw away a real property of the artifacts: they need van Rossem to be accepted on-chain. Record that as a new schema field, min_protocol_version: 11, rather than leaving it in prose only. The floor was measured rather than assumed, and the measurement changed the model. vanRossemPV is first defined in plutus-core 1.59.0.0 and absent in 1.58.0.0, which suggested 1.59 as the minimum evaluator. Evaluators built at both versions disprove it: 1.58.0.0 executes the casing artifacts and the dropList ones alike, every test passing, because CAPE evaluates through defaultCekParametersForTesting, which enables all builtins regardless of protocol version. A min_plutus_version floor measures when plutus-core's CEK gained a capability, not what mainnet accepts, so it is the wrong instrument for this. min_plutus_version is now documented as what it always operationally was: an evaluator-routing knob, set only when the production evaluator cannot run an artifact at all. It stays unset everywhere. min_protocol_version is documented as not enforced during measurement, since the testing machine parameters ignore protocol gating. ADR Refinement 4 records the measurement and the resulting split.
Unisay
marked this pull request as ready for review
August 14, 2026 09:58
Seven submissions declared source_available: true with no source_commit_hash, and named IntersectMBO/UPLC-CAPE as the source repository. The provenance was not actually missing: each one's source/README.md already records the repository, branch and commit. Only metadata.json was stale, left over from before the Plinth source moved out of this repo (ADR 20260520). All six Plinth 1.61 submissions plus htlc/Plinth_1.45.0.0_Unisay_asdata now carry the commit their own README names, b09485c75e3ab6b596b9613320abc2b325087612 on branch plinth-1.61 of Unisay/plinth-cape-submissions. That commit is titled "Bootstrap Plinth source tree from UPLC-CAPE 04bb0a3", i.e. it is the move itself, and every path the seven READMEs cite exists there. two_party_escrow already carried its own later pin from #230 and is untouched. This reconciles metadata.json with source/README.md; it does not certify that the artifacts rebuild from that commit, which would need the 1.61 toolchain. The three Aiken submissions still without a pin are a different and legitimate model: they ship their real source in-tree (aiken.toml, lib/, plutus.json, fib.ak) rather than pointing at an external repository.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Van Rossem activated on mainnet on 2026-07-18 (protocol version 11), so builtin casing and the batch-6 builtins are production features, and
plutus-tx-plugin1.67 removed thedatatypes=BuiltinCasingoption outright. The preview track has nothing left to preview. Second half of #242; stacked on the evaluator bump, and should merge right after it.All 30
_previewsubmissions move onto the production track:min_plutus_versiondropped, theBuiltinCasingandvanRossementries dropped fromflags,min_protocol_version: 11recorded in their place, prose reframed, and each directory renamed onto the non-casing sibling it was compiled from, which is then retired. No_previewdirectory remains and nothing declaresmin_plutus_version, socape submission measure --previewreports no submissions. That is the correct steady state until something targets protocol version 12, and the machinery stays in place re-aimed at 1.67.Why the requirement is a protocol version, not a plutus version
Dropping
min_plutus_versionand stopping there would have thrown away a real property of these artifacts: they need van Rossem to be accepted on-chain. So the floor was measured rather than assumed, and the measurement changed the model.vanRossemPVis first defined inplutus-core1.59.0.0 and absent in 1.58.0.0, which suggested 1.59 as the minimum evaluator. Evaluators built at both versions disprove it: 1.58.0.0 executes the casing artifacts and thedropListones alike, every test passing. CAPE evaluates throughdefaultCekParametersForTesting, which enables every builtin regardless of protocol version, so amin_plutus_versionfloor measures whenplutus-core's CEK gained a capability and never measures what mainnet accepts.The requirement worth recording is therefore the protocol version, which is what gates these builtins on-chain and does not move when CAPE's evaluator does.
min_protocol_versionis a new schema field, documented as not enforced during measurement.min_plutus_versionis now documented as what it always operationally was, an evaluator-routing knob for the separate case where the production evaluator cannot run an artifact at all, and it stays unset everywhere.Which sibling each casing build replaces
Not always
default. The rule is that a casing build replaces the sibling it was actually compiled from, decided per submission by source pin, and every promotion has to show a measured win over what it replaces.For 27 of the 30 that sibling is
default, and the headline fee improves by 13% to 32%. Three Plinth 1.64 submissions are the exception. Their casing artifacts share a source commit with the_plainor_asdatavariant, because they were built before the monadic decoder landed for that line:Plinth_1.64.0.0_Unisay(monadic, default)284f04a9..._plain63eaf4b8..._preview(casing)63eaf4b8Promoting those onto
defaultwould have swapped in artifacts 111% to 153% more expensive and put a regression into the 1.64 column that reflects a source revision, not a compiler feature. They replace_plainand_asdatainstead, where they win by 7.7%, 28.1% and 31.3%, and the monadic default for that line is untouched.Result
73 submissions, all measured on
PlutusTx.Eval-1.63.0.0, all verified with nothing skipped. The evolution report shows four mainnet columns for both Plinth and Scalus and no preview teaser; the Plinth timeline gains a 1.61 point that was previously preview-only.The pre-fork non-casing artifacts for the promoted lines are gone from the working tree. They stay in git history, and the surviving
_plainand_asdatavariants still provide a non-casing comparison wherever one was already published.ADR
ADR 20260526 gains Refinement 4 recording the promotion, the matching-pin rule, and the evaluator measurement behind the
min_protocol_versionsplit. Two of its earlier claims, that aCAPE_CURRENT_PLUTUS_VERSIONbump would re-derive the track classification for free, are marked superseded: Refinement 2 had already moved report routing to the directory-name suffix, which is what made this a migration rather than a no-op.