[feature] Core: define how Capabilities declare that no current closed-set RiskLabel applies

[rainypilgrimage]

Problem

Moss requires every Capability to declare a risk field, but Registry rejects an empty list:

if (meta.spec.risk.length === 0) {
  throw new Error(`capability "${config.name}.${name}" must declare a risk label`);
}

The current closed set is:

[
  "fundOut",
  "approval",
  "priceImpact",
  "debt",
  "leverage",
  "liquidation",
]

The semantics accepted in #114 and implemented in #119 define:

• fundOut: assets leave the account in the current transaction;
• debt: the Capability increases the account?s repayment obligations, even when no asset leaves in the current transaction.

Those definitions resolved debt-increasing borrow, but they also made a residual authoring gap explicit.

Core currently has no valid authored state for:

The Capability author has reviewed the operation, but none of the current closed-set RiskLabels accurately applies.

Omitting risk is invalid, an explicit empty list is rejected, and a non-empty list may force the author to select a label known to be inaccurate.

Confirmed cases

aPriori claim

During requestRedeem, the owner?s aprMON shares are transferred into vault custody. The later claim settles that request and pays matured MON to the receiver.

The exposed claim transaction does not move an asset out of the account or create a repayment obligation. fundOut, debt, approval, and priceImpact therefore do not describe this Capability.

The adapter currently retains:

risk: ["fundOut"]

with a comment recording that the operation is inflow-only and that the label is a Registry-compatible placeholder. Although #119 has since added debt, that label does not fit claim because completion does not increase a repayment obligation.

Source:

moss/packages/protocols/apriori/src/adapter.ts

Lines 185 to 198 in 97df9c1

	@Capability<AprioriProtocol, typeof claimParams>({
	intent: "Claim MON for withdrawal request {requestId} to {receiver}",
	verb: "claim",
	params: claimParams,
	receipt: "claimReceipt",
	// claim is inflow-only, but Registry rejects an empty risk list and the
	// closed RISK_LABELS set has no inflow/obligation label yet (#114).
	// Drop fundOut here as soon as #114 lands a correct minimal set.
	risk: ["fundOut"],
	tags: ["staking", "liquid-staking", "withdrawal-queue"],
	})
	async claim(params: InferParams<typeof claimParams>) {
	const transaction = this.aprMon.redeem([[BigInt(params.requestId)], params.receiver]);
	return [transaction];

FastLane completeUnstake

FastLane has the same transaction shape. requestUnstake commits the shMON in an earlier transaction; after the epoch completes, completeUnstake only pays MON from FastLane to the owner.

The integration-branch comment says that fundOut ?does not fit,? notes that Registry rejects an empty risk set, calls the declaration the ?least-wrong placeholder,? and points to #12 and #104 for the pending ruling.

The declaration nevertheless remains:

risk: ["fundOut"]

The payout direction is supported by a real Monad-mainnet completion transaction documented in #158.

Source:

moss/packages/protocols/fastlane/src/fastlane.ts

Lines 195 to 210 in 8357d33

	@Capability<FastLane, typeof completeUnstakeParams>({
	intent: "Complete a delayed unstaking request after epoch completion",
	verb: "unstake",
	params: completeUnstakeParams,
	receipt: "completeUnstakeReceipt",
	// This step is inflow-only: requestUnstake already committed the shMON, and
	// completion only pays MON back to the owner. `fundOut` as settled in #114
	// means assets leave the account in this transaction, so it does not fit,
	// but Registry rejects an empty risk set and the closed set has no
	// inflow-only entry. Kept as the least-wrong placeholder pending the ruling
	// asked for in #12 and #104.
	risk: ["fundOut"],
	tags: ["staking", "unstake", "delayed"],
	})
	async completeUnstake() {
	return [this.staking.completeUnstake([])];

Why this needs a Core decision

load() exposes risk separately from free-form tags. A placeholder therefore becomes part of the structured contract an Agent reads rather than remaining an internal adapter comment.

Registry currently enforces a non-empty invariant: every registered Capability must provide at least one Core classification. This can prevent omitted classification, but the confirmed cases show that it can also force a known-inaccurate label when the closed set contains no applicable category.

?No current Core RiskLabel applies? is not a safety, trust, or execution-policy decision. Mandatory simulation, Receipt and Warning handling, pre-signing presentation, wallet review, and user approval remain unchanged.

It means only that none of the current Core-defined static danger categories accurately describes the operation.

Proposed direction

Keep the risk field required, but allow an explicitly authored empty list:

risk: []

For a Capability, define this as:

The author has reviewed the operation and determined that none of the current closed-set Core RiskLabels accurately applies.

The field remains required, missing or malformed metadata remains invalid, every non-empty member remains closed-set validated, and load() projects the authored empty list unchanged.

The public shape is already RiskLabel[], and Query stubs already project an empty list. This would not require a new TypeScript, JSON, or MCP data shape.

It would nevertheless be an Agent-facing semantic compatibility change. Consumers that rely on Registry?s runtime guarantee that every Capability has at least one RiskLabel would need to stop making that assumption, so the change should be documented and released accordingly.

The strongest objection is that an empty list could become an easy opt-out if contributors use it instead of analysing the operation or proposing a missing reusable danger semantic. The authoring rule below is intended to prevent that use.

Authoring decision rule

risk: [] must not be used merely because the existing labels are inconvenient or because the operation has not been fully analysed.

When no current RiskLabel accurately applies:

1. If the Capability exposes a recurring static danger that the current closed set cannot represent, contributors should raise a focused Core vocabulary issue.

   The issue should provide concrete Capability evidence, define the proposed semantic boundary, compare existing labels and alternatives, and wait for a maintainer decision before implementation?the sequence demonstrated by [feature] Clarify RiskLabel semantics for debt-increasing lending capabilities #114/feat(core): add debt risk label #119.

2. If no current label applies and, after reviewing the operation?s static dangers, no distinct reusable danger semantic has been identified from the evidence, an explicitly authored risk: [] may represent that result.

3. If the classification remains uncertain, the contributor should request Core or maintainer review rather than use an inaccurate placeholder or treat risk: [] as a substitute for analysis.

If Core later defines an applicable RiskLabel, an existing risk: [] declaration should be replaced with that label.

Alternatives considered

Add fundIn

This preserves the non-empty invariant, and the FastLane author explicitly preferred this direction over risk: [] in #158 for that reason.

Its advantage is that every Capability continues to have at least one Core-defined classification. The tradeoff is that receiving funds is not itself a category of danger. fundIn would broaden RiskLabel toward a general asset-direction taxonomy, while the representation question may recur for operations that have neither an applicable danger label nor a pure-inflow shape.

Add a sentinel such as noApplicableRisk

This preserves a non-empty list and explicitly represents the author?s conclusion.

However, the sentinel is not a danger category and would require combination rules to reject contradictory states such as:

risk: ["noApplicableRisk", "approval"]

It would mix classification status with the RiskLabel taxonomy.

Other alternatives

• Making risk optional would conflate a deliberate decision with omitted metadata.
• Broadening fundOut to historical or flow-level outflow would contradict [feature] Clarify RiskLabel semantics for debt-increasing lending capabilities #114/feat(core): add debt risk label #119.
• Free-form tags do not replace the structured risk contract exposed by load().
• Structured severity, conditions, review status, or dynamic risk objects are outside this representation question.

Maintainer decisions requested

1. Should Core allow an explicitly authored risk: [] when none of the current closed-set RiskLabels applies, while keeping the field required?

   If Core should preserve the non-empty invariant, an alternative accurate public representation would resolve the same adapter pressure without relying on known-inaccurate placeholders.

2. Should the canonical meaning and authoring guidance distinguish:

   • a missing reusable danger semantic, which should follow the focused Core vocabulary process demonstrated by [feature] Clarify RiskLabel semantics for debt-increasing lending capabilities #114/feat(core): add debt risk label #119; and
   • a reviewed operation for which no current danger category applies?

3. Should the focused Core implementation establish the public representation, validation, coverage, documentation, authoring rule, and changeset, while leaving adapter adoption to coordinated follow-up work?

Suggested acceptance coverage

For the maintainer-approved representation, the focused Core implementation should:

• implement the representation while keeping risk required;
• reject missing, malformed, and unknown metadata;
• cover Registry registration, validation, and exact load() projection;
• preserve compile-time required-field and closed-set guarantees;
• update the canonical glossary, MCP documentation, and short Protocol-onboarding rule;
• include the Core changeset and pass the full pnpm lint ? build ? typecheck ? test verification chain.

The focused Core PR may close this issue once the approved public contract and coverage land.

Adapter adoption is downstream work and should not block closure of the Core issue. aPriori adoption can be handled in a separately coordinated follow-up without expanding #159, while FastLane adoption should be coordinated with the existing #12/#158 contributors. Each affected adapter package can carry its own appropriate changeset.

Scope

This issue is limited to the Core authoring representation for a Capability when none of the current closed-set RiskLabels accurately applies.

It does not:

• redesign the broader RiskLabel taxonomy;
• define liquidation, leverage, severity, or dynamic account risk;
• change Warnings, Receipts, simulation, or Agent policy;
• require aPriori or FastLane implementation changes in the Core PR;
• expand the ABI-provenance and authentic claim-log scope of apriori: record the open-source search in the ABI header, and test the claim Receipt against real logs #159;
• assign or supersede the adapter work discussed in Adapter: FastLane shMONAD staking #12 or fix(fastlane): authenticate Receipt evidence and bind transfer endpoints #158.

Related work and attribution

• [feature] Clarify RiskLabel semantics for debt-increasing lending capabilities #114 established the debt-increasing RiskLabel problem and the accepted fundOut boundary.
• feat(core): add debt risk label #119 implemented and documented the accepted debt semantics.
• The aPriori counterexample was surfaced in the #104 maintainer review.
• The FastLane counterexample was reported in the #12 report and supported with real completion evidence in fix(fastlane): authenticate Receipt evidence and bind transfer endpoints #158.
• The author of fix(fastlane): authenticate Receipt evidence and bind transfer endpoints #158 explicitly preferred adding fundIn over allowing risk: [] in order to preserve the non-empty invariant; this issue retains that position as an alternative for the Core decision.
• apriori: record the open-source search in the ABI header, and test the claim Receipt against real logs #159 is separately scoped to aPriori ABI provenance and authentic claim-log coverage.

This issue extracts the shared residual Core question made explicit by the accepted #114/#119 semantics. It does not supersede the concrete adapter findings, implementation work, or attribution above.

This issue does not claim implementation ownership. A focused Core PR can follow the maintainer decision.

[nishuzumi]

For anyone picking this up — worth two minutes first.

Moss is one of the pool repos in MOST, the Monad Open Source Track, which the Monad Foundation runs to back people doing public, original open-source work on Monad. It pays in AI credits toward the tools you build with, and the amount grows the longer you sustain the work.

Taking a scoped issue like this one and carrying it through review is precisely what it counts. What it looks for is public repos, original code, a steady cadence across the month, and contributions that get merged — the merge is the bar, and every one is reviewed by a human. It reads your public GitHub activity, so there is no separate log to keep.

Applying takes a form: email, GitHub handle, a short note on what you are building and why, and a Telegram handle so they can reach you. Applications are reviewed manually, so a real sentence about your work is worth more than a filled field.

Apply here: https://most.devnads.com/

[zkasuran]

The attribution in the alternatives section is accurate. I argued for fundIn in #158's
description, for the reason recorded here: every Capability keeps at least one Core
classification, so an Agent reading load() never has to tell an authored empty list from a
Capability nobody classified.

The FastLane evidence behind that case, since this issue cites it. completeUnstake pays
matured MON from the FastLane vault to the owner and takes nothing from the account. The
shMON was committed by requestUnstake in an earlier transaction. A real Monad-mainnet
completion is in #158, where the Receipt parser binds both endpoints of that payout and its
amount, so the direction is measured rather than assumed. fundOut on that declaration is a
placeholder and it is wrong.

I am not attached to the representation. Both directions fix the adapter. If risk: [] is
the ruling, the authoring rule in this issue is the part that keeps it from becoming an
opt-out. It should ship with the change rather than after it. I will implement whichever
one is chosen, core side plus the FastLane adoption, as soon as the ruling lands.

A decision here unblocks two adapters that both carry a knowingly inaccurate label today,
aPriori claim and FastLane completeUnstake. I have not opened a core PR and will not
before the ruling, which is the #114 to #119 sequence this issue names.

[portdeveloper]

@zkasuran you already hold a claim on haythemsellami/mpamm.wtf#6, and the pool rule is one claim per person at a time. Finish or release that one first, then claim here again.

[rainypilgrimage]

Thanks @zkasuran for confirming the attribution and adding the FastLane evidence. I agree that, if risk: [] is selected, the authoring rule should land in the same Core change rather than as a later follow-up.

Your comment also made me notice that the final line of the issue is broader than I intended. Saying that the issue “does not claim implementation ownership” was meant to avoid starting a Core implementation before the maintainer decision, and to avoid displacing the adapter work already under discussion. It was not meant to say that I had no interest in implementing the resulting Core change.

I had hoped to follow the same issue → ruling → implementation sequence as #114/#119, and I would be glad to implement the focused Core change once the representation is decided. I agree that we should avoid parallel Core branches. I am only volunteering for the Core portion here; I am not asking to take over the FastLane work under #158 or to expand #159.

@nishuzumi, once the representation is decided, could you let us know how you would prefer the focused Core implementation to be coordinated? If you would like me to implement it, I would be happy to do so. If you prefer another arrangement, I am also happy to coordinate and independently review the result so that we do not duplicate work.

[rainypilgrimage]

@portdeveloper, one MOST process clarification: I applied on 3 August under the GitHub handle rainypilgrimage and am still awaiting manual review. While the application is pending, should I wait before asking to take an implementation here, or can the maintainer coordinate it on the issue first and the formal MOST claim follow after acceptance?

[zkasuran]

Thanks both.

@rainypilgrimage on the Core change: go ahead and take it. You opened the issue and you have the clearest picture of the representation you want, so the focused Core PR is yours once @nishuzumi decides fundIn versus risk: []. If risk: [] is the ruling I agree the authoring rule belongs in that same Core change rather than a later follow-up, so an authored empty list can never read as a Capability nobody classified. I will keep #158 scoped to the FastLane adapter and move it onto whichever representation lands. Glad to review your Core PR against the FastLane evidence when it is up.

@portdeveloper understood on the one-claim rule. The substantive part of haythemsellami/mpamm.wtf#6, the structured state.notes shape, already merged as #35 over there. The piece still open is the retraction follow-up haythemsellami outlined on that issue: give the archive and gap-fill notes the same retract-then-recover lifecycle 6c3cf5b gave the starvation warning. I will close that out so the claim frees up. I am not claiming this issue while it is open.

[zkasuran]

@portdeveloper quick correction on the sequence, because I think the comment read as a claim on this issue. It was not. I answered the fundIn versus risk: [] question because the issue asks for that representation call. The Core implementation now goes to @rainypilgrimage, who opened the issue and volunteered for it. No second claim from me here.

The claim you flagged, haythemsellami/mpamm.wtf#6, is not idle. Its substantive change was the structured state.notes shape the issue was redirected to. That merged as mpamm #35 on 4 August. What is left is the retraction follow-up outlined on that issue, which I am finishing now to close #6. That is a claim carried through to a merge, not a stacked one.

[portdeveloper]

@rainypilgrimage thanks for the interest. Claims on the pool repos are open to admitted MOST participants. Apply at https://most.devnads.com and claim again once you are in.

[portdeveloper]

@rainypilgrimage correction from my side: you had already applied on Aug 3 and I missed it when I pointed you at the application page above. Your application is in the review queue and you will hear back by email. Once you are admitted, the claim flow here works the usual way.

[rainypilgrimage]

I would like to claim this issue for the focused Core implementation.

I am prioritizing this issue because one Core decision can provide a shared representation for the current aPriori, FastLane, and Merkl inflow-only cases, allowing their downstream metadata to be updated consistently. This should not block unrelated adapter work while the decision is pending.

I will keep the work within the issue’s current boundary:

• wait for @nishuzumi’s decision on fundIn versus risk: [] (or another approved representation) before changing Core code;
• implement only the approved Core contract, validation, Registry/load() coverage, documentation and authoring guidance, changeset, and full verification;
• leave downstream adapter adoption under the existing FastLane, Merkl, and aPriori workstreams, tracked by fix(fastlane): authenticate Receipt evidence and bind transfer endpoints #158, feat(protocols): add Merkl rewards claim adapter for Monad mainnet #187, and apriori: record the open-source search in the ABI header, and test the claim Receipt against real logs #159.

While the representation decision is pending, I will keep progress updates here and avoid opening a parallel implementation branch. Once the representation is decided, I will open the focused Core PR and keep its implementation and evidence scoped to this issue.

[nishuzumi]

Decision: Core will allow an explicitly authored risk: [], with risk remaining required.

Semantics: the author has reviewed the operation and determined that none of the current closed-set RiskLabels applies. Missing or malformed risk stays invalid, every non-empty member stays closed-set validated, and load() projects the authored empty list unchanged.

Not adding fundIn. Receiving funds is not a category of danger, and the non-empty invariant does not buy what it claims: Registry checks presence, not accuracy, and today's three fundOut placeholders are the proof. An honest empty list beats a false label.

Constraints for the Core PR:

1. The authoring rule (Core vocabulary issue first when a reusable danger semantic is missing; [] only after review; maintainer review when uncertain) ships in the same change, in CONTEXT.md, docs/mcp-tools.md, and the onboarding template.
2. A Capability declaring risk: [] must have Receipt test coverage asserting that no Change moves assets out of the account. [] is a claim the Receipt can refute, not a comment.
3. Changeset flagging the Agent-facing semantic change.

@rainypilgrimage the Core PR is yours. Adapter adoption stays with #158, #187, and the aPriori follow-up.