Skip to main content
A HEVN account owner can invite other users to help manage the balance — for example, a founder adding a finance teammate. This is not implemented as a platform-level permission that HEVN enforces off-chain. It is implemented directly at the wallet layer, using two standards built by Coinbase for Base smart wallets.

​
Two access modes

​
Full access: MultiOwnable

Coinbase’s Smart Wallet contracts include MultiOwnable, an auth module that maintains a set of owners onchain. Key properties:
  • Owners are stored as bytes — an owner can be a 32-byte-padded Ethereum address or a 64-byte secp256r1 (passkey) public key.
  • Owner management is itself owner-gated. Adding an owner (addOwnerAddress / addOwnerPublicKey) or removing one (removeOwnerAtIndex) requires a signature from an existing owner.
  • Every owner’s signature is validated by the wallet contract for each user operation under ERC-4337.
A full owner is a peer: they can spend any amount and manage the owner set. Grant full access only to people you would trust with the entire balance. See Base’s documentation on Base Account, where multi-owner support is a core feature of every smart wallet.

​
Limited access: Spend Permissions

For everything short of full trust, HEVN uses Spend Permissions — an onchain primitive from Coinbase that lets a wallet owner grant another account the right to spend a precisely bounded amount. A permission is a signed SpendPermission struct with explicit constraints: How it works onchain:
  • The SpendPermissionManager singleton contract is registered on the wallet and enforces the permission logic: it tracks cumulative usage within each period and rejects anything beyond the allowance.
  • When a new period begins, usage resets to zero — enabling recurring budgets (“this account may spend up to 1,000 USDC per month”).
  • The spender cannot exceed the allowance, touch other tokens, or change wallet ownership. The constraints are contract-enforced, not policy-enforced.
  • The owner can revoke the permission onchain at any time, immediately ending the spender’s access.

​
How HEVN uses it

1

Invite

The account owner invites another HEVN user by email and chooses the access mode — full ownership or a spend allowance. Because every HEVN user’s Privy address is deterministic from their email, HEVN can resolve the invitee’s key immediately.
Invite member dialog with role, operations, spending limit and expiry

Inviting an operator with a 500 USDC monthly spending limit — the allowance and period become the onchain SpendPermission

2

Grant — signed by the user, not HEVN

The account owner signs the grant: an owner-addition operation for full access, or a SpendPermission for limited access. HEVN prepares the operation and sponsors its gas, but cannot execute it — only the owner’s signature makes it valid.
3

Shared management

The invitee signs operations with their own key through their own email login — unrestricted as an owner, or within the allowance as a permitted spender. No key material is ever shared between users.
Team management page showing an owner and an operator with a 500 USDC allowance refreshing in 30 days

The team view mirrors the onchain state: the operator's remaining allowance, its refresh period, and expiry

4

Revocation — also onchain

The account owner removes an owner with removeOwnerAtIndex, or revokes a spend permission via the SpendPermissionManager. Once confirmed onchain, the removed key can no longer act on the wallet. Revocation does not depend on HEVN’s cooperation or uptime.

​
Why this design is safe

Platform roles (who can see invoices, edit contacts, etc.) are managed separately by the HEVN API under the platform JWT. Onchain ownership and spend permissions govern money; platform roles govern metadata. HEVN’s app keeps the two in sync when you manage teammates.

​
References