Ecosystem scaffolding

Gummiworm’s protocol is only part of what it takes for L2s to work well for ordinary users. Wallets need to surface L2 balances. dApps need a standard way to connect to L2s. Users need to be able to read what they are signing, even when parts of the payload are encrypted. And scripts need a way to detect which ledger context they are executing in. These are not internal Gummiworm concerns — they are the scaffolding that makes Gummiworm and L2s in general useful in a multi-L2 ecosystem.

L2 state query API

Cardano wallets track user balances by querying the L1 for utxos at known addresses. For L2s, this does not work: a user’s funds in a Gummiworm head reside in the evacuation map, not in any L1 utxo.

A semi-standardized L2 state query API would let wallets display user balances across any L2 that implements the interface, without bespoke integrations. At minimum, the API should support:

• Balance query: given a public key hash, return the total value the user holds in the L2, broken down by asset.
• Position query: return the user’s open positions — open orders, locked funds, pending deposits — in a normalized form.
• Discovery: a mechanism for a wallet to learn which L2s a user has funds in, without exhaustively querying every known L2.

For Gummiworm, the evacuation map is the natural canonical source for balance queries. A wallet integration that reads it through a standard API would give users a real-time view of their Gummiworm funds without any head-specific knowledge.

CIP-30 L2 extensions

CIP-30  defines the standard dApp connector interface for Cardano wallets. A dApp calls enable() to connect, and uses the resulting API to sign transactions and query L1 state. There is no standard way for a dApp to connect to an L2 through this interface.

The common workaround — a “switch network” selector in the wallet UI — places the integration burden on the wallet and forces users to manage network context manually. A better model: the enable() call accepts a list of L2 network identifiers, and the returned API object exposes L2-scoped methods alongside the existing L1 ones. A dApp like Sugar Rush could declare upfront that it requires a Gummiworm connection, and the wallet handles the rest.

The L2-scoped API methods would cover at minimum: submitting L2 transaction requests, reading the user’s L2 balance, and signing L2 data. This would let users experience L2 interactions as natural extensions of their existing wallet flow, rather than a separate application.

Wallet signing with field-level encryption

Users signing Gummiworm requests should be able to see exactly what they are authorizing. If a wallet presents a hash, a ciphertext, or opaque hex fields, the user is partially blind to what she is signing — a well-known attack vector where a malicious frontend shows a friendly description but submits something different to the wallet.

This is in tension with Sugar Rush’s encryption model: the L2 payload is encrypted for the TEE so that head peers cannot read and discriminate against requests before they are ordered. The user must sign the request containing the ciphertext, not the plaintext, because Gummiworm verifies the signature immediately upon receiving the request — before assigning a request ID or broadcasting to other peers.

The ideal solution is a CIP extending the Cardano wallet signing interface to support field-level encryption annotations. The signing payload would be a structured COSE envelope in which individual fields are annotated as either plaintext (shown to the user as-is) or to-be-encrypted (shown in plaintext for display, encrypted by the wallet before signing). The wallet verifies that the ciphertext it produces from the annotated fields matches the intended ciphertext, then presents the full plaintext to the user for approval before signing the encrypted form.

Wallet vendors may resist the added complexity. We may need to adapt Gummiworm’s user request structure and signature verification to work with simpler primitives that wallets are willing to support — the design space here remains open.

UPLC script context registry

Plutus scripts on Cardano receive a script context as a UPLC data term. The outermost constructor tag identifies the context type. When the same script is deployed on an L2 — as Gummiworm’s EUTXO L2 ledger executes Plutus scripts — it receives a similarly structured context, but one whose semantics differ from Cardano L1. A script with no way to distinguish these contexts may behave incorrectly, or may inadvertently accept invocations in an environment it was not designed for.

A community-maintained registry of UPLC script context constructor tags — managed via a CIP, analogously to how CIP-67  manages asset name label prefixes — would assign a distinct tag to each execution environment: Cardano L1, Gummiworm EUTXO L2, and others as they emerge. Scripts that need environment-specific behavior can branch on the tag; scripts that should only run on L1 can assert it as a guard; scripts designed to be portable across L2s can handle multiple tags explicitly.