Should wallets make revocable delegation a first-class feature?

I’m building a wallet for shared equipment and community-owned digital assets, and I keep running into the same missing primitive: temporary, revocable delegation. A member should be able to use a tokenized 3D printer, software license, membership, or collectible without receiving the owner’s keys or getting a permanent transfer.

The usability case is obvious, but the failure modes are not. Who can revoke access, and is revocation immediate? Can a borrower use a cached credential offline? Does granting or cancelling require multisig approval? If the wallet vendor, delegation manager, or relay disappears, can the owner still recover control? Standards such as ERC-4907 and draft proposals like ERC-7710/7715 point in this direction, but they do not magically create interoperable wallet behavior or settle what “ownership” means legally.

I worry wallet-native delegation could simply turn vendors into new gatekeepers. Would you trust it for something valuable? Concrete examples or counterarguments welcome.

Revocation is the part demos usually hand-wave. If the device accepts an offline credential, “revoked” can only mean revoked after the device reconnects or checks some short-lived lease. That may be fine for a printer, but not for a sensitive license or access-controlled facility. The policy needs to name the enforcement point.

I’d ship this only if the UI makes delegation feel like lending, not transferring. “Use until Friday” is understandable; “grant capability set 0x…” is not. The commercial catch is support: users will blame the wallet when the underlying issuer, device, or contract has a different idea of access.

Multisig approval should be configurable, not mandatory for every low-risk loan. A community treasury might require two approvers for a month-long equipment lease, while an individual lends a collectible for an afternoon. The threat model changes with duration, value, and whether the delegate can cause irreversible effects.

The standards distinction matters here. ERC-4907 separates NFT owner and user roles with an expiry, while ERC-7710 and ERC-7715 address broader delegation or wallet permissions. None of that establishes a universal legal category. A contractual right to use something should not be presented as ownership merely because the interface says “owned.”

The wallet company disappearing is less scary if delegation state is portable and intelligible: signed records, documented schemas, and a way to reconstruct the owner’s authority from the underlying account. If the only usable copy of the permission lives in a vendor database, it is not really decentralized from the user’s perspective.

There is also a social problem: revocation feels neutral in a protocol diagram and personal in a club. If a member’s access vanishes without an explanation, they will ask the community, not the standard, what happened. Good audit history and plain-language reasons may matter as much as the cryptography.

My counterargument is that this may be another name for an access-control list with worse nouns. If the equipment operator still decides who gets admitted, maintains the service, and handles disputes, the wallet has not removed the gatekeeper. It may only have moved the login screen.

Recovery needs an owner-level path and an operator-level path. Replacing a lost phone should not accidentally restore every delegate, and revoking one borrower should not require rebuilding the whole community account. I’d want explicit emergency procedures tested before launch, not just a recovery paragraph in documentation.

Delegation can reduce key sharing, but it may increase observability. A centralized relay or permission service could learn who is using which asset and when, even if it cannot spend the asset. Privacy-preserving issuance and local verification would be worth treating as requirements rather than future polish.

I’m less worried about vendors becoming gatekeepers if users can switch providers. I’m more worried about the issuer retaining the real veto through contract terms or device firmware. Portability solves interface dependence; it does not necessarily solve dependence on the thing that recognizes the right.

The boring test: kill the RPC, disconnect the wallet, expire the permission, rotate a signer, and restore from backup. Then ask which operations still work and which fail closed. If the answer is undocumented, delegation is not a feature yet; it is a distributed failure mode with a nice name.