Wallets & Signing

Who owns a wallet, who can authorise its signatures, and what TetraFi can and cannot do with it.

Every wallet stays under its owners’ control. TetraFi never moves funds without the owners’ approval, or a limited grant they approved. TetraFi describes each wallet with the same few fields, so you can see at a glance who controls it and what it can do.

​

The fields on every wallet

Field	Answers	Values
Scope	Who owns it	Organisation: the company’s wallet, the one that faces LPs and brokers. Personal: one member’s wallet.
Shared	Who else may use it	Organisation wallets are always workspace-wide. Sharing a personal wallet with chosen members (view and request, nothing more) is not yet available.
Control	Who can authorise a signature	Governed, Embedded, Self-managed or Custodian (below).
Key technology	How the key signs	MPC, secure enclave, HSM, threshold network, a custodian-managed key, or an external key TetraFi knows nothing about. A contract account has no key of its own; each of its owners has one.
Account type	What the chain sees	An ordinary address, an address with EIP-7702 smart features (shown as Smart (7702)), a multisig contract, a modular smart account, or a custodian ledger.
Wallet type	The label you see	The smart-account kind for a contract account, otherwise the key technology and provider, such as “MPC · Fireblocks”.
TetraFi role	What TetraFi can do	None, or bounded delegate (below).
Verification	Is ownership proven	Verified, or Unverified: a registered or imported wallet before its signature proof. An unverified wallet can’t send.

Scope and control are independent. A personal wallet can be governed, and a company can hold an embedded wallet, though Treasury warns against it: a single login controls it, so use a governed wallet for company money.

​

Control: who authorises a signature

Control	Who signs	What TetraFi does with it
Governed	A quorum of approvers or factors, enforced by the provider or a contract. You set the quorum, 1 of 1 included.	Prepares requests; your quorum approves them.
Embedded	One person’s login on a provider-hosted wallet.	Acts in that person’s own session, or through a limited grant they approve.
Self-managed	You, by connecting your wallet and signing.	Sends only when you connect and sign. Everything else is monitored only.
Custodian	A regulated custodian.	Sends instructions and reads balances. The custodian’s own approvals still apply.

Exchange and OTC venue accounts and bank accounts are separate kinds of account, not wallets.

​

TetraFi’s role

TetraFi is infrastructure: it never signs, sends or acts for you on its own.

• None. TetraFi can read the wallet and prepare requests. Every signature needs the owners.
• Bounded delegate. The owners approve a limited signer, for example for an automation or an agent. The provider enforces its limits; a limit the provider can’t enforce is refused, with the reason. Revoking it stops new sends.

TetraFi checks who holds a wallet’s native owner roles. A personal wallet’s owners count as yours only when a complete read shows every factor as permanent and none of them as TetraFi’s; a failed read, or a factor TetraFi can’t attribute, reads as unread, never as yours. If any owner role is held by a TetraFi key, the wallet reads Control changed and every send from it is refused. The fix is in the provider: remove TetraFi’s signing rights there.

A recovery share is the one other role TetraFi will ever accept, and it is not yet available. With it, TetraFi would hold one share of a wallet key for recovery only: it never signs alone, never counts toward a quorum, and the wallet stays self-custodied. You would opt in per wallet.

​

Where new wallets are created

A new organisation wallet is created with one of two kinds of provider:

• A platform provider, operated by TetraFi. TetraFi runs the provider account, so you need no provider contract of your own. The wallet’s owners are still your members’ factors. TetraFi’s account holds no owner role and is at most a bounded delegate. Privy is available as a platform provider. Turnkey as a platform provider is coming and can’t be chosen yet; until then, choosing it is refused and nothing changes.
• Your own provider connection. You connect your own Turnkey or Privy account, and wallets are created in it.

Each wallet shows which one it uses, for example “Privy, operated by TetraFi” or “your Turnkey connection Treasury ops”.

​

A wallet stays where it was created

Every wallet is pinned to the provider and connection it was created with. The workspace’s choice decides only where new wallets go. Changing it never moves an existing wallet. Every earlier wallet keeps reading balances and sending on its own provider.

​

Switching where new wallets go

When existing wallets would stay behind, a switch needs your acknowledgement. Without it, the switch is refused and nothing changes. The refusal lists, for each provider and connection, how many organisation wallets and members’ personal wallets stay there. Switching between two connections of the same provider counts as a switch too. Members’ personal wallets are counted, never named.

​

Moving a wallet to another provider

Switching doesn’t move money. To move a wallet’s funds to another provider:

1. Create a new organisation wallet on the provider you want.
2. Use Move funds from the old wallet to the new one. This is one Run with a step per asset, and the network coin goes last. The wallet’s owners approve it like any other send.
3. Retire the old wallet once it is empty.

A wallet can’t be retired while it is:

• holding a balance;
• part of an open Run;
• holding funds reserved for a payment;
• the source of an active grant;
• the workspace’s saved default.

Each refusal names its cause. Network-coin dust smaller than one transfer’s fee can’t be sent, so it stays in the wallet and remains under its owners’ control. A retired wallet keeps its history, but it can’t send or receive again.

​

Removing a provider connection

A connection that any wallet or pending setup still uses can’t be removed. The refusal counts what still uses it. To free the connection:

• move and retire the organisation wallets that use it;
• each member removes their own empty personal wallets on it (only the member can do this).

Once nothing uses the connection, it can be removed.

​

What each provider supports today

Yes: the provider enforces it. Partial: part of it works. Monitored: TetraFi checks it and refuses what breaks it, but the provider doesn’t enforce it. No: not available today.

Capability	Turnkey	Privy	Fireblocks	BitGo
Create the wallet from TetraFi	Yes	Yes	No	No
Send and sign by API	Yes	Yes	Yes	Yes
Sign typed data	Yes	Yes	Yes	Partial
Owner quorum	Yes	Yes	Partial	Partial
Approve inside TetraFi	Yes	Yes	No	No
Per-transaction caps	Yes	Yes	Yes	Yes
Rolling spend limits	Monitored	Monitored	Yes	Yes
Allow-list of destinations	Yes	Yes	Yes	Yes
Bounded delegate (automations, agents)	Yes	Yes	No	No
Expiry on a delegation	Yes	Yes	No	No
Install a policy from TetraFi	Yes	Yes	No	No
Read back the enforced policy	Yes	Yes	Yes	Partial
Freeze	Yes	Yes	Yes	Yes
Outcome updates	Partial	Partial	Yes	Yes
Recovery	Provider	Provider	Provider recovery kit	Backup key

Wallet gas sponsorship and transaction batching are not yet available for any provider. API-submitted escrow orders already land with no gas from your wallet. Safe multisigs and modular smart accounts are not yet available. Providers that are not yet available appear greyed out when you add a wallet.

​

The rule that holds everywhere

An API key, an admin session, a provider connection or a gas sponsor never creates wallet authority. Per-chain defaults are preferences, never authority: ownership is checked again before every send. Every wallet or grant request carries a request ID you generate, so a lost response reconciles under it and nothing is created twice.

Where delegated signing enters the loop is on Orders; the same wallets move funds under policy on Treasury & Custody.