[DOCS] handles page, and the onchain ACP sharing registry

[alexandrecarvalheira]

Item 3 on the queue: a home for wrap/unwrap, and a proper explanation of onchain shared ACPs.

New page: handles, wrap, and unwrap

unwrap and wrap existed only as bare signatures in the utility reference, which left unanswered the question they actually raise. The new page answers it.

Both are internal pure casts over the same bytes32. No cryptography, no TaskManager call, no storage. The load-bearing point:

Wrapping grants nothing. The type records what kind of value this is. The ACL decides whether you may use it. wrap touches only the first.

So FHE.wrapEuint32(someHandleFromAnEvent) succeeds, and the first FHE operation on it reverts. That asymmetry is the thing worth writing down, because the cast looks like acquisition and isn't.

The page covers when unwrap is right (generic bytes32 slots, events, mapping keys, identity comparison as distinct from FHE.eq), when wrap is right (recovering a handle the contract already owns), and the case where neither is: a value that arrived from outside. That routes to the typed forms rather than a guarded bare handle, since there is one for every way a value can reach you.

Value came from	Type	Conversion
A user, offchain	externalEuintXX + bytes proof	FHE.asEuintXX(handle, proof)
Another contract, as an argument	sharedEuintXX	receiveEuintXXParam, checks sharer is msg.sender
Another contract, as a return value	sharedEuintXX	receiveEuintXXFromCall, checks sharer is the callee
Your own storage	euintXX	wrapEuintXX

Placed after inputs in Core Concepts, which is where the type families are introduced.

Onchain ACP sharing, expanded

Four lines and a code block became a method table with the actor, the transaction-versus-read distinction, and the registry config shape.

Verified against the published ACP page, not just the SDK source, which corrected four things I had wrong or missing: shareOnChain returns { txHash, shareId }; getIncomingShares filters to still-importable shares; importFromChain also stores and activates the ACP; and cancelShare only works on a share not yet imported.

One claim removed. I had written that dismissShare and cancelShare "do the same thing, either side can clear a share." The first half is true, both resolve to the same removeShareOnChain(shareId) in the SDK. The second half was my inference from identical implementations, and I never verified what the registry contract authorizes per caller. The note now says only what I can back.

Also adds the privacy caveat: posting onchain makes the issuer-to-recipient relationship public, which the offline route avoids.

Vale and lint-docs.py exit 0. mint validate and mint broken-links --check-anchors --check-redirects pass.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
fhenix	🟢 Ready	View Preview	Aug 28, 2026, 3:11 PM