Recurring Payments#

Recurring Payments are how Hightop handles repeat payments to known vendors.

Instead of letting an agent pay anyone at any time, you approve the vendor first, set limits, define the conditions, and then allow the agent to operate inside those boundaries.

This is a simple but powerful idea: approve the relationship once, automate the payment flow after that.

The relationship is bound to a specific vendor record in Hightop (called a Payee in Underscore Protocol): the vendor you recognize, the payout address behind it, and the asset rules, caps, cadence, timing, and expiry tied to that relationship. Those records and their limits are enforced onchain by open-source smart contracts — an agent cannot quietly swap the destination or widen the lane just because it has API access.

When to Use Recurring Payments#

Use this path when an agent needs to pay a known vendor more than once.

Common examples:

data providers
model inference APIs
compute vendors
specialized agent services
API subscriptions
recurring contractor or payroll-style relationships

If the destination is known and the payment pattern is repeatable, this is usually the right mechanism.

Why This Exists#

Without a recurring payment model, you usually end up in one of three bad states:

manually re-entering payment details over and over
giving an agent too much freedom
moving funds out of productive balances just to keep bills current

Hightop avoids that tradeoff.

You approve the vendor, define the limits, and let the agent handle the approved flow.

The Control Model#

Recurring Payments separates who may be paid from who may execute the payment.

You (through your control wallet) set things like:

which vendors are approved
which relationship rules apply
how much they can receive
how often they can be paid
when access should start
when access should expire

The agent can then execute payments inside that approved lane, but it cannot silently widen the relationship.

Agent Permissions for This Path#

Recurring Payments have their own path-specific permission model.

There are three separate questions:

can an agent pay active recurring vendors at all
can an agent propose a new recurring vendor for approval
can the vendor initiate payment directly (vendor-initiated billing, also called pull payments)

That last case means the approved vendor can initiate a payment under the relationship's caps and timing rules, instead of waiting for you or an agent to push it.

At the Hightop level:

an agent needs recurring-payment permission before it can execute payments on this path
the account can allow or disallow agent proposals for new recurring vendors
a proposed vendor still requires owner confirmation before it becomes active
each recurring relationship can allow or disallow vendor-initiated billing
the account must also allow vendor-initiated billing at the path level before any individual vendor can use it

Paying an active recurring vendor is not the same thing as adding a new one, and vendor-initiated billing is a separate capability again.

What Gets Fixed in the Relationship#

When you create a recurring payment relationship, you are usually locking in:

the vendor record you approved in Hightop
the payout address tied to that vendor
the recurring period window
an optional transaction-count limit
an optional cooldown
an optional activation delay
an optional expiry date
whether missing price data should block payment on this relationship
whether vendor-initiated billing is allowed
how asset rules should work for that vendor
amount-based limits (caps in the payment currency itself, not just dollar value)
USD-denominated limits

That is what makes this path feel stable. The relationship is defined up front, then reused safely.

Who Controls the Vendor List#

Recurring vendors are not meant to be fluid.

In the safest setup, you manage them directly. An agent can also be given permission to propose a pending recurring vendor, but it still cannot activate or widen that relationship on its own. The account owner must confirm any proposed vendor before it becomes active.

The important controls stay with you:

confirmation of pending vendors after the delay
updates to the relationship's editable rules
which payout address is attached to that vendor
which limits apply
the initial activation delay and active lifetime
removal or recreation if that timing needs to change

A vendor can also remove itself from the relationship. You, the pending vendor itself, or an emergency security action can cancel a pending recurring vendor before it becomes active.

An agent can run the approved payment flow, but it does not get unilateral authority to add a live recurring vendor, widen the caps, or replace the payout address.

Account-Wide Recurring Payment Rules#

Some controls apply to the recurring-payment path across the whole account. Others apply to each vendor relationship.

Account-wide recurring payment rules can define:

Default period window: the default recurring window for new vendors, such as 1 day, 1 week, or 1 month. This is the time basis for per-period payment caps and payment-count caps unless a specific relationship overrides it.
Account-wide transaction count limit: the maximum number of recurring payments allowed in a period across this path.
Account-wide cooldown: the minimum waiting time between recurring payments across this path.
Account-wide USD limits: the outer recurring-payment ceiling for per-payment, per-period, and lifetime value.
Fail on missing price: whether recurring payments should be blocked when the system cannot establish the price data needed to evaluate USD-based limits. If you set account-wide USD caps for recurring payments, this protection needs to be on.
Vendor-initiated billing master switch: whether this account allows vendor-initiated billing at all.
Default activation delay: the default delay before a newly added recurring vendor becomes active.
Default active lifetime: the default duration before a recurring vendor expires automatically.

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

Per-Vendor Rules#

Each recurring relationship can then define its own more specific rules:

Period window: the recurring window for that vendor relationship.
Transaction count limit: the maximum number of payments allowed in that period.
Cooldown: the minimum waiting time between payments.
Activation delay: a waiting period before the recurring relationship becomes active.
Expiry: an automatic end date for that relationship.
Fail on missing price: whether that specific relationship should block payment when price data is unavailable. If you set USD limits on that relationship, this protection needs to be on there as well.
Vendor-initiated billing enabled: whether that specific vendor may initiate payments directly.
Primary asset: the asset Hightop treats as the main token for that relationship.
Only primary asset: whether the vendor is locked to that one asset only.
Unit limits: token-denominated per-payment, per-period, and lifetime caps for the primary asset.
USD limits: dollar-denominated per-payment, per-period, and lifetime caps for the relationship.
Creation-time timing: activation delay and expiry are set when the recurring relationship is created.

Later updates can change the relationship's caps, cadence, asset rules, and vendor-initiated billing setting, but they preserve the existing start and expiry timing. If you need different timing, remove the relationship and create a new one.

How Account Rules and Relationship Rules Combine#

Recurring Payments use both account-wide and per-vendor rules at the same time, following the general stacking model described in Agent Permissions and Limits: the tighter rule always wins. That applies to payment-count limits, cooldowns, USD-based caps, and missing-price protection.

Timing has its own combination rules specific to this path:

if a relationship does not set its own period window, it inherits the account default
a per-vendor activation delay can only make the wait longer, not shorter
a per-vendor active lifetime can only make the lane shorter, not longer

A narrower relationship rule cannot be bypassed by app or backend logic — these combined checks are enforced by the control layer.

Dual Limit System#

Recurring Payments support both token-unit limits and USD-value limits.

They solve different problems:

unit limits are useful when a vendor should receive a fixed token amount
USD limits are useful when you want value-based protection across volatility

How they work together:

unit limits apply when the payment uses the relationship's primary asset
USD limits apply whenever the system can price the payment
account-wide and per-vendor rules are both checked
the tightest applicable rule wins

This lets you build relationships like:

"up to 1,000 USDC per month"
"up to $5,000 of value per month"
or both at the same time

Asset Modes#

Recurring Payments can be configured in a few different ways:

Single-asset relationship: lock the vendor to one token only. For example: USDC only — no other token accepted. Good for payroll or subscription relationships where the currency should never vary.
Primary-asset relationship: set a primary asset for unit-based tracking, while still allowing broader value-based controls. For example: USDC is the tracked currency for monthly unit caps, but other stablecoins may be accepted if they fit the USD cap.
Broad relationship with USD controls: use USD-denominated controls without locking the vendor to one token. For example: any supported asset, capped by dollar value. More flexible, but less specific than a single-asset lane.

Vendor-Initiated Billing (Pull Payments)#

Recurring Payments can work in two directions.

Push: you or an agent initiates the payment to the approved vendor.
Pull (vendor-initiated): the approved vendor claims payment directly within the configured limits.

Vendor-initiated billing is useful for:

subscriptions
usage-based billing
services that charge at predictable intervals

Even with vendor-initiated billing enabled, payments remain bounded by the configured rules. No vendor gets unlimited access just because they are approved.

The right mental model is double activation:

the account must allow vendor-initiated billing
the specific recurring relationship must also allow it

Both conditions need to be true.

Vendor-initiated billing also requires real limits. A vendor with pull access must have at least one unit or USD cap. Hightop does not treat this as unlimited open-ended debit authority.

Separation of Powers#

This is one of the most important design ideas in the whole section.

With Recurring Payments:

you approve or confirm the relationship
the agent runs the approved payment flow

An agent can keep a service online without being able to invent a new vendor, swap the payout address, or widen the spending cap on its own.

Lifecycle of a Recurring Vendor#

A recurring relationship moves through stages:

Added or Proposed: You add it directly, or an agent proposes it as pending.
Pending: If it came through the proposal path, it waits for owner confirmation behind the delay.
Active: The relationship can now be paid within its rules.
Expired or Removed: The recurring lane no longer works until it is recreated or renewed.

This lifecycle is part of why this path is safer than just storing a vendor address in app settings.

Recipient Rules#

Recurring Payments are for approved service vendors, not for every destination type.

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

When to Use a Different Payment Path#

If the vendor is new or the payment is ad hoc, use One-Off Payments instead. If the destination is one of your own highest-trust addresses and you need instant transfer, use Trusted Transfers.

Example Configurations#

Data Provider#

USDC only
1 payment per month
25-day cooldown
$300 per month
vendor-initiated billing enabled

Inference API#

USDC primary asset
100 payments per month
6-hour cooldown
$1,000 per month
vendor-initiated billing enabled

Compute Vendor#

USDC only
$100 per payment
$750 per week
20 payments per week
agent pushes payment
one-hour cooldown

Specialized Agent Service#

primary asset relationship for stablecoin billing
$2,000 per month
10 payments per month
90-day expiry tied to the service agreement

Payroll or Contractor Lane#

USDC only
1 payment every 2 weeks
$5,000 per period
180-day expiry tied to the contract term
vendor-initiated billing disabled, you or an agent pushes payment

What Can Still Block a Recurring Payment#

Even if a vendor is approved, a payment can still fail if:

the agent lacks recurring-payment permission
the vendor is still pending or not active yet
the payment exceeds a cap (per-payment, per-period, or lifetime)
the payment-count cap for the period is already used
the cooldown has not elapsed
the asset does not fit the relationship's asset rules
required price data is missing and the relationship blocks on missing price
vendor-initiated billing is not enabled both at the account-wide level and for that relationship
the recurring relationship expired
the agent's own narrower vendor restrictions block that vendor

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