The spec's own answer here is narrower than "encrypted" — opacity is a client-side contract, not a server-side security requirement. From the pagination spec:

Clients MUST treat cursors as opaque tokens: Don't make assumptions about cursor format, don't attempt to parse or modify cursors, don't persist cursors across sessions.

There's no MUST/SHOULD anywhere about the server signing or encrypting the cursor — the spec's own example ("nextCursor": "eyJwYWdlIjogM30=") decodes to plain {"page": 3}, unsigned. So strictly by spec, base64(JSON) already satisfies "opaque": it's a token the client isn't supposed to introspect, not a secret the server is obligated to protect.

Where it becomes a real concern is the scenario you and the pagination proposal both gesture at: if the server trusts an unsigned cursor's offset/filter fields without re-deriving or re-validating them against the current request, a client can hand-construct or replay a cursor to jump to a page it shouldn't reach — past a permission-filtered boundary, or against a different tool/argument set than the one that issued it. That's not a violation of the pagination spec (the client never parsed anything), it's a server-side trust bug — same class as IDOR-via-pagination-token seen plenty in REST APIs. HMAC/signing the cursor to the params that produced it, plus a TTL, is the right fix for that — but it's server-side hygiene the spec is silent on, not something "opaque" currently requires.