One-Off Payments#

One-Off Payments are how Hightop handles ad hoc payouts to recipients that are not part of a recurring payment relationship.

Instead of turning every payment into an instant, irreversible transfer, Hightop can treat a one-off payment as a controlled payment commitment. Small spends can clear quickly. Larger payouts can sit behind a review window and remain cancellable until they are claimed or executed.

That gives you a path for flexible spending without blind trust.

It also means funds do not have to leave your account the moment the payment is created.

A good mental model is: a one-off payment is closer to a payment commitment than an instant irreversible transfer.

Key terms like recipient, amount, unlock timing, and expiry are enforced by the onchain control layer — not just stored as app metadata.

When to Use One-Off Payments#

Use this path when:

the recipient is new
the purchase is ad hoc
the payment is not expected to repeat
you want review time before a larger amount clears

Common examples:

buying a one-time dataset
paying for a temporary compute job
buying output from a specialized agent
paying for a single external API task

Why This Exists#

Ordinary transfers are all-or-nothing.

Once funds leave, there is no review window, no graceful correction path, and no cancellation option.

That is especially risky when:

the destination is unfamiliar
the amount is large
an agent is initiating the spend
you want time to confirm the purchase or deliverable

One-Off Payments separates approval from final execution.

Fast for Small Payments, Delayed for Bigger Ones#

One of the most important controls in this path is the threshold between instant and delayed payments.

if a one-off payment is below your configured instant threshold, it can clear immediately
if it is above that threshold, it waits behind the configured review delay before it can be paid or claimed

That gives you a practical balance:

small everyday spends can stay fast
larger payouts pause long enough for you to catch a rogue agent, a compromised API key, a bad destination, or a mistaken amount before funds move

That delay is a safety buffer. If an agent starts behaving unexpectedly or an API key is compromised, you still have time to cancel a larger payout before funds move.

This is one of the clearest examples of why One-Off Payments exist. You do not have to choose between "everything is manual" and "every ad hoc payout clears instantly."

What Gets Fixed at Creation#

When a one-off payment is created, Hightop fixes the important terms up front:

recipient
asset
amount
unlock time or review delay
expiry window
whether the recipient can claim it directly

If one of those terms needs to change, the answer is not "edit it in place." The safe pattern is to cancel it and create a new one.

Agent Permissions for This Path#

One-Off Payments have their own path-specific permission model.

There are three separate questions:

can an agent create a one-off payment
can an agent execute or pay an existing one-off payment
can the recipient claim it directly

At the Hightop level, this means:

an agent needs one-off payment creation permission before it can create them at all
the account can allow or disallow agent-created one-off payments for this path
the account can allow or disallow agent-paid one-off payments for this path
each individual one-off payment can decide whether agent payment is allowed
each individual one-off payment can decide whether recipient claim is allowed

Creating a one-off payment, paying it, and claiming it are related, but they are not the same permission.

The Payment Lifecycle#

A One-Off Payment moves through stages:

Created: The payment commitment is written.
Waiting: A review or delay period applies if configured.
Claimable or Executable: The payment can now clear.
Finalized: The payment is either completed, cancelled, or expired.

This is what makes the path safer than a direct irreversible transfer.

Who Can Create and Who Can Cancel#

Here, "you" means the person controlling the account (through your control wallet).

At a high level:

you can always create and cancel one-off payments
an agent can only create them if it has that permission
the account must also allow agent-created one-off payments for that agent path
the agent that created a one-off payment cannot cancel it
only you, or an emergency security action, can cancel it before it is finalized
a recipient can only claim them if claim behavior is enabled and the payment is ready
an agent can only pay an existing one-off payment if agent payment is allowed both for the path and for that specific one-off payment
a cancellation can only happen before the payment is finalized
neither the agent nor the recipient can rewrite the destination or amount after creation
a recipient claim clears the payment as written, not a partial slice of it

If a one-off payment is cancelled or expires before clearing, the funds do not disappear somewhere else. They remain in your account and are available for other uses.

Controls You Can Apply#

Some controls apply to the one-off payment system as a whole. Others apply to each payment you create.

Account-Wide Rules#

These settings define how the one-off payment path behaves across the account:

Maximum active count: limit how many unpaid one-off commitments may exist at once. This prevents an agent or workflow from creating an unbounded queue of pending obligations.
Maximum value: set the largest amount allowed for a single one-off payment.
Instant threshold: set the value below which a one-off payment can clear immediately. Above that threshold, Hightop applies the larger delayed-payment rules for this path. For example, if set to $100, payments under $100 can clear immediately while payments above $100 go through the configured review delay.
Default review delay: define the default review delay for larger one-off payments. This is the automatic waiting period applied when a payment exceeds the instant threshold.
Default expiry: define how long a one-off payment remains valid once it becomes active. If it is never claimed or executed in that window, it expires.
Period window: define the recurring window used for one-off payment creation and payment caps, such as value created per period, number created per period, value paid per period, and number paid per period.
Creation period caps: limit how much value can be committed through new one-off payments in the current period window.
Maximum number created per period: limit how many new one-off payments can be created in the current period window.
Creation cooldown: require waiting time between creating one-off payments. This helps prevent runaway creation loops.
Payment period caps: limit how much value can actually clear through one-off payments in the current period window.
Maximum number paid per period: limit how many one-off payments can actually be paid in the current period window.
Payment cooldown: require waiting time between actual one-off payment executions.
Allowed assets: restrict one-off payments to a defined asset list.
Agent create toggle: define whether agents are allowed to create one-off payments through this path at all.
Agent pay toggle: define whether agents are allowed to execute existing one-off payments through this path at all.
Recipient pull toggle: define whether recipient-initiated claims are allowed for this path at all.

These account-wide rules are enforced boundaries, not just app defaults. If a payment fits the specific one-off record but violates the account-wide one-off rules, it still fails.

Per-Payment Rules#

Each individual one-off payment can also carry its own terms:

Review delay: set a custom waiting period before that one-off payment becomes claimable or payable. Larger payments can wait behind a configured delay. This gives you time to review the action before funds actually move.
Expiry window: set a custom validity window for that payment. If a one-off payment is never claimed or executed, it can expire automatically.
Agent payment allowed: decide whether agents are allowed to execute that specific payment once it becomes ready. This is separate from the account-wide agent-pay toggle. Both must allow it.
Recipient claim allowed: decide whether the recipient can claim the payment directly once it is ready. This is separate from the account-wide recipient claim setting. Both must allow it.

Creation vs Payment Limits#

This path tracks creation and payment separately.

That means Hightop can limit:

how many one-off payments get created
how much value gets committed through creation
how many one-off payments actually get paid
how much value actually clears

Creating a payment commitment and finalizing a payout are not the same risk. These two stages are checked separately, so a payment cannot bypass creation controls just because it clears later.

Cancellation Window#

Keep the payment cancellable until it is actually claimed or executed.

This is the core protection that makes a one-off payment different from a normal transfer.

If an agent goes rogue or its API key is compromised after a delayed one-off payment is created, the review window gives you time to cancel before funds move.

The delay and payment terms are enforced by the control layer, not just by a front-end timer or backend policy check.

Why It Works Well for Agents#

One-Off Payments are especially useful for agents because they preserve flexibility without forcing you to pre-approve every new destination forever.

An agent can:

make small ad hoc purchases quickly
create larger payments that wait behind a review window
operate within a bounded spending lane

At the same time, you still keep control:

the amount can be limited
the timing can be delayed
the payment can be cancelled before it clears

Recipient Rules#

One-Off Payments are for destinations that are not already part of your more trusted payment lanes. A one-off recipient cannot already be a recurring payment vendor or a trusted transfer destination. Each payment path is kept distinct.

When to Use a Different Payment Path#

If the destination is known and the relationship is ongoing, use Recurring Payments instead. If the destination is one of your own highest-trust addresses and you want instant transfer, use Trusted Transfers.

Example Use Cases#

Small Dataset Purchase#

A research agent buys a $25 dataset from a new provider. The amount is below the instant threshold and clears immediately.

Large Compute Job#

An agent initiates a $5,000 payment for a one-time job. The payment waits behind a 3-day review window before it can clear.

Specialized Agent Service#

A one-time $3,000 payment is created for a specialist agent that delivered a single report or task, without creating a long-lived recurring relationship.

What Can Still Block a One-Off Payment#

An action can still fail if:

the agent lacks one-off payment permission
the account does not allow agent-created or agent-paid one-off payments for this path
the amount exceeds a configured cap
the review period has not elapsed
the payment expired or was cancelled
the asset is not allowed
creation or payment cooldown rules were hit
the path-level creation or payment period caps were hit
the recipient is not allowed to claim (if claim behavior is disabled at the account-wide level or for that payment)

For the full diagnostic checklist, see If an Agent Goes Off-Script.