Trusted Transfers#

Trusted Transfers are the highest-trust payment path in Hightop.

They are meant for destinations you trust deeply, usually your own wallets, reserve destinations, emergency safe locations, or your own connected external bank accounts for ACH or bank wire withdrawal. Once a destination is approved for Trusted Transfers, transfers to it can happen immediately and without the normal recurring-payment or one-off-payment recipient caps and delays.

This is also the payment lane Hightop uses for withdrawals to your own connected bank accounts.

This is powerful. It is also the path that requires the most trust.

If you configure this path carelessly, you are removing exactly the friction that protects you everywhere else.

That is why the delay matters so much. Adding a new trusted destination is not just a waiting room in the UI. The time delay is enforced by the onchain control layer.

How This Fits the Recipient Model#

Hightop has three recipient paths:

• Recurring Payments for approved repeat vendors with recurring controls
• One-Off Payments for ad hoc payouts with review windows and cancellation
• Trusted Transfers for your highest-trust destinations

A direct transfer needs to fit one of these recipient paths.

Trusted Transfers is the fast lane in that model.

If a destination is active here, the transfer does not go through the normal recurring-payment or one-off-payment recipient checks. That is why this list should stay short and extremely deliberate.

The trusted destination list is part of the onchain control model, not a private allowlist in app or backend logic.

When a Destination Belongs Here#

Trusted Transfers exists for one specific job: moving money quickly to destinations you trust at the highest level.

Use this path when:

• the destination is your own wallet, reserve destination, recovery destination, or connected external bank account
• you need fast internal capital movement
• you want an emergency exit path
• recurring-payment caps or one-off-payment delays would add unnecessary friction

A destination belongs here only if all of these are true:

• you control it directly, or trust it at that same level
• you would be comfortable sending a large balance there immediately
• you do not need recurring-payment caps or one-off-payment review windows for that destination

Common examples:

• moving funds to cold storage
• routing money between operating and recovery accounts
• transferring to another Hightop-controlled destination
• moving money back to your own connected external bank account
• emergency evacuation of funds

If the destination is a vendor, contractor, customer, or newly discovered address, it probably does not belong here.

Trusted Transfers is treated differently from the other payment paths. Once a destination is trusted, transfers to it can bypass much of the normal friction. Reserve this path for addresses you truly trust, not ordinary vendors or casual recipients.

Key Security Behavior#

The most important protection in this model is the approval process for adding a trusted destination.

The usual pattern is:

• additions are delayed
• removals are immediate

That gives you time to catch a bad or malicious addition before it becomes active, while still letting you react instantly if a trusted destination ever becomes unsafe.

That delay is often measured in days, not minutes. It follows the account's security timelock (a mandatory waiting period enforced by the control layer), not just a front-end timer.

Pending trusted destinations are also tied to the control wallet that created them. If control of the account moves to a different wallet before confirmation, that pending entry can no longer be confirmed as-is. It must be cancelled and re-added under the new control wallet.

Who Controls Trusted Destinations#

Trusted destinations are not meant to be casually editable.

You manage this list yourself (through your control wallet). The important controls are:

• who may add a new pending trusted destination
• who may confirm it after the delay
• who may cancel a pending destination
• who may remove an active destination

In Hightop, adding a new pending trusted destination is reserved for your control wallet. Agents do not get to introduce new trusted destinations.

If Hightop exposes deeper trusted-list management, confirmation, cancellation, and removal can still be treated as separate high-trust actions. But that is different from adding a new destination in the first place.

An agent may use a trusted destination only if that destination is already active and the agent has permission to use this path.

Once the destination is active, transfers skip the normal recipient-level caps and review windows. If an agent initiates the transfer, that agent's delegated limits and safety checks still matter. If the control wallet initiates the transfer, those agent-delegated caps do not apply — any amount already in the smart contract wallet can be moved immediately to an active trusted destination.

The delay and activation model are enforced by the control layer — a destination that has not been added and activated cannot be used.

Destination Rules#

A trusted destination cannot already be a recurring payment vendor or the recipient of an active one-off payment. Each payment path is kept distinct.

The practical takeaway: recurring vendors belong in Recurring Payments, ad hoc recipients belong in One-Off Payments, and trusted destinations belong here only when they are truly high-trust transfer targets.

Why Delayed Additions Matter#

The risk this delay is built for is compromise of the control wallet or other account-control access. If an attacker gets that control and trusted destinations could be added instantly, they could create a new destination and move funds out immediately.

With delayed additions, that path is broken:

1. the bad destination enters a waiting period
2. you have time to spot the change
3. you can cancel it before it becomes active
4. you can move funds to an already trusted safe destination if needed

This is specifically not the agent threat model — agents and API keys cannot add new trusted destinations in the first place. The delay exists for compromise of the account owner, not of a single agent.

The delay protects the add path. It does not protect you if a bad destination is already active in the trusted list, which is why that list must stay short and limited to your own highest-trust destinations.

Pending and active are not just UI labels. They are real states in the control layer, and this is one of the most important security ideas in the whole control model.

Why This Matters#

This design creates two important benefits:

Fast Internal Movement#

You can move capital between your own trusted destinations without recurring-payment caps or one-off-payment delays slowing you down.

Emergency Defense#

If something feels wrong, you can move funds to a trusted safe destination immediately, while new malicious destinations remain stuck behind a delay.

If a destination is not active in the trusted list, the transfer fails before funds move.

When to Use a Different Payment Path#

If the recipient is a known vendor with an ongoing relationship, use Recurring Payments instead. If the payment is ad hoc and you want delay and cancellation controls, use One-Off Payments.

Examples#

Cold Storage#

Move funds from an active operating account to a safer long-term destination.

Reserve Routing#

Move capital between an agent operating account and a separate long-term reserve or recovery destination.

External Bank Withdrawal#

In Hightop, your own external bank accounts connected through Bridge, a Stripe company, can be treated as trusted withdrawal destinations. That gives you a familiar off-ramp back to your bank account while keeping the control path explicit.

Emergency Exit#

If you suspect compromise or need to react quickly, move funds to a pre-approved safe destination immediately.

Keep this list short. A short trusted list is easier to reason about, easier to review, and safer in an emergency.

What Can Still Block a Trusted Transfer#

A transfer can still fail if:

• the destination is not approved or still waiting for activation
• the agent lacks permission to use this path
• the agent hit a higher-level limit or cooldown
• the destination was removed

If the destination is not already active in the trusted list, the transaction fails before funds move. For the full diagnostic checklist, see If an Agent Goes Off-Script.