OpUp Is an Interface Decision

Designing compute boundaries on Algorand

Hook

Algorand does not give every application call an unbounded amount of work. Opcode budgets are real, cumulative, and easy to hit once you chain logic, validate state, or compose with other contracts. When you run out of room, the fix is rarely "write faster TEAL." It is usually where you choose to spend units and who you expect to fund them.

What OpUp Is (Briefly)

OpUp (opcode budget increase) is the mechanism that raises how much computation a contract invocation may consume. In practice it is how you say: this step is allowed to be heavier than the default.

It is not a performance knob in isolation. It is a boundary: who triggers the increase, at what layer of the transaction, and who bears the cognitive and operational cost of that choice.

Two Approaches

Outer (group-level)

OpUp is applied outside the application's core entrypoints typically coordinated as part of a transaction group or caller-orchestrated packaging. The caller (wallet, router, aggregator, or another contract) ensures sufficient budget exists before your logic runs "for real."

Plaintext sketch:

Group:
  [0] pay / opt-in / routing setup (if needed)
  [1] app call A
  [2] app call B  ← caller added OpUp here so B can finish

The protocol's on-chain code stays simple; the interface pushes complexity to whoever assembles the group.

Inner (in-contract)

OpUp is initiated inside the contract or behind abstractions your contract owns so your code path requests or inherits the budget it needs. Externally, integrators call you with a shape closer to "one logical operation," even if the chain still does multi-step work under the hood.

Plaintext sketch:

User → AppCall: execute_swap(params)
         └─ internally: budget increase + core logic + checks

The protocol owns the story of "how heavy this is" and hides group mechanics from casual integrators.

Core Insight

OpUp is not only a technical detail. It is an interface and ownership decision.

• Outer OpUp = caller responsibility: composability and transparency come with assembly cost.
• Inner OpUp = protocol responsibility: simplicity and encapsulation come with internal discipline.

You are choosing whether compute constraints live in your public integration surface or inside your implementation frontier.

Developer Experience

Outer OpUp

Pros

• Keeps individual app interfaces minimal; less "magic" inside each contract.
• Makes budget usage visible at the group layer for advanced integrators.
• Can align with explicit, pipeline-style composition (build the group you need).

Cons

• Every integrator must understand opcode budgeting and correct ordering.
• Easy to ship insecure or brittle examples that "work on my machine" but fail under contention.
• Debugging shifts to transaction archaeology (who failed to fund units?).

Inner OpUp

Pros

• Lowers the integration burden: fewer valid ways to get it wrong.
• Centralizes policy: you can enforce consistency, monitoring, and upgrades in one place.
• Easier to document a single happy path.

Cons

• Obscures where units go unless you expose metrics, events, or docs.
• Increases internal complexity; mistakes become your outage, not theirs.
• Harder for power users who want full manual control of every opcode.

User Experience

Outer OpUp

Pros

• Power users and builders can optimize paths and feel "in control."
• Wallets and explorers may show more granular steps if that is surfaced well.

Cons

• End users hit opaque failures ("group rejected") when a downstream integrator mis-budgets.
• More moving parts between intent ("swap," "deposit") and what actually lands on-chain.

Inner OpUp

Pros

• Users experience one primary action aligned with their mental model.
• Fewer footguns for light clients and third-party UIs that wrap your protocol.

Cons

• Less transparency into internal substeps unless you deliberately reveal them.
• Users depend on your implementation staying within trustworthy bounds.

System-Level Tradeoffs

The rows are not "good vs bad." They are where you want friction to live.

Design Guidance: When to Use Each

Prefer outer OpUp when

• Your protocol is deliberately a primitive: you want advanced callers to compose freely and accept responsibility for budgets.
• You need maximum auditability of each step for a specialized audience.
• You are building infra where explicit pipelines are the product.

Prefer inner OpUp when

• Your product is an end-to-end workflow and most callers should not assemble groups by hand.
• You want to avoid exporting internal constraints (opcode shapes, ordering quirks) as part of your public API.
• Consistent UX matters more than exposing every substep.

Avoid pushing internal opcode choreography to users unless that exposure is intentional and documented as part of your contract's model.

Principle

If the system already knows how much compute the operation needs, fund it internally.

Deferring OpUp to every integrator is a valid design only when unpredictability or caller-specific optimization is the point. If the needed budget is a function of your own logic, owning it inside the protocol is usually the cleaner boundary.

Closing: Abstraction and Ownership

Opcodes are low-level. Interfaces are not. Every extra requirement you place on callers group layout, ordering, supplemental calls is complexity you have chosen to export.

OpUp forces the question in concrete terms: Is this constraint part of my user's job, or mine? Answer that honestly, and the right placement (outer vs inner) follows.

TL;DR

• OpUp placement is an interface decision, not just a performance trick.
• Outer shifts budget responsibility to callers; inner keeps it with the protocol.
• Trade transparency vs simplicity and composability vs explicit control deliberately.
• Do not export internal opcode constraints to users unless that is a designed part of your API.
• If compute needs are known and stable for your flows, fund them internally rather than scattering assumptions across integrators.

Suggested featured image: Minimal dark-blue field with a single soft gradient; a thin luminous line or plane suggests a boundary between two regions (caller vs protocol), no text, no logos.

Alternative title: Where OpCode Budget Becomes Your Public API