If you’ve used Padre to trade memecoins at any point over the last two years, there’s a good chance you’ve noticed something different lately: the name. Padre is now called Terminal, and the change isn’t cosmetic — it’s the result of an acquisition that quietly reshaped one of the most important pieces of infrastructure in memecoin trading. Pump.fun, the platform behind the majority of Solana memecoin launches, bought Padre and folded it directly into its own ecosystem.
This guide covers everything current on Terminal in 2026: what actually changed in the rebrand, what the platform does today, how its features stack up against competitors, and what the Pump.fun ownership means for anyone using it going forward.
Here’s the timeline, because it matters if you’re a PADRE token holder or you’ve been away from the platform for a while. Padre was acquired by Pump.fun in late 2025, and the rebrand to “Terminal” followed shortly after. As part of the transition, the PADRE token lost its utility on the platform entirely. A snapshot was taken on October 24, 2025, requiring PADRE holders to submit their Solana wallet addresses to claim PUMP tokens, with a claim deadline of December 30, 2025. If you were holding PADRE and didn’t submit your claim in that window, it’s worth checking directly with the team on whether any recovery path still exists — but the original token itself no longer functions as a platform utility token.
Functionally, very little changed for traders using the product day to day. The same self-custodied wallet architecture, the same order panel across supported chains, and the same official trading interface at trade.padre.gg carried over. What changed is who owns it, what it’s called, and — most importantly for anyone tracking the broader ecosystem — how its revenue now flows. Terminal’s fees are explicitly named as one of the three revenue sources (alongside Pump.fun’s bonding curve and PumpSwap) feeding into Pump.fun’s PUMP token buyback-and-burn program, a detail covered in more depth in our companion piece on $PUMP tokenomics.
If you’re arriving at the platform searching for “Padre” and landing on something called “Terminal,” you’re in the right place. Same product, same team lineage, new name, new ownership.
Terminal positions itself as a full memecoin trading terminal — not just an order execution screen, but a combination of four functional layers wired into one interface:
An execution layer — the actual buy/sell mechanics, order types, and trade settlement.
A discovery layer — surfacing new and trending tokens before they’re widely known, including tools specifically built for tracking tokens on bonding-curve launch platforms.
A risk layer — automated checks designed to flag or block trades that carry elevated rug-pull or exploit risk.
A portfolio layer — unified tracking of holdings, PnL, and performance across every chain you trade on, in one dashboard instead of four separate wallet views.
That combination is the core pitch: instead of bouncing between a block explorer, a separate charting tool, a wallet tracker, and a DEX interface, Terminal consolidates the entire memecoin trading workflow into a single screen.
Multi-chain execution. Terminal currently supports trading across Solana, Ethereum, Base, and BNB Chain, letting you manage positions on all four networks from one interface rather than switching wallets and tools every time you cross chains.
Execution speed. The platform advertises average execution times around 300 milliseconds, aimed squarely at the kind of high-frequency, first-in scenarios that define memecoin trading — new listings, migrations, and bonding-curve graduations where being seconds late can mean the difference between an entry and a chase.
Trenches. This is Terminal’s dedicated tool for tracking tokens launched via bonding-curve platforms, specifically Pump.fun on Solana and Four.meme on BNB Chain. Trenches organizes tokens into three stages — New (early in the bonding curve), Almost Bonded (nearing the end of the curve, often where activity spikes), and Recently Bonded (freshly graduated to a liquid market) — with real-time metrics, wallet tagging, and dev-behavior signals layered on top. You can toggle which metrics display on each token card and switch between Solana and BNB Chain views from the top of the screen. Given that Pump.fun now owns Terminal outright, Trenches’ tight integration with Pump.fun-launched tokens specifically makes a lot more sense than it might have as a purely third-party tool.
Wallet tracking and copy trading. Terminal lets you follow specific wallets and mirror their trades in real time — a feature widely used to track known high-performing traders or “smart money” wallets and react to their positioning as it happens.
MEV protection, rug detection, and slippage control. Every trade routes through checks intended to catch smart-contract red flags, protect against sandwich attacks and other MEV extraction, and keep slippage within a range you set rather than letting a thin order book eat your fill.
Automated order types. Limit orders, trailing stops, and take-profit automation are all built in, letting you set an exit strategy in advance instead of babysitting a chart — a meaningful advantage in a market where price can move double digits in minutes.
Non-custodial architecture. Private keys are encrypted client-side with a password only the user holds; the team has no access to it. This matters specifically in memecoin trading, where custodial platforms have historically been a common target and single point of failure.
Progressive Web App support. Terminal runs as a PWA, meaning you can install it directly from your mobile browser and use it like a native app on both iOS and Android without going through an app store — useful given how much memecoin trading activity happens from a phone in real time.
Independent reviews describe Terminal as landing somewhere between two of the other major names in this space: Axiom and Photon. Axiom is generally viewed as the more structured, pro-oriented option, built around a more elaborate fee system and deeper tooling aimed at high-volume traders. Terminal, by comparison, leans toward accessibility and real-time responsiveness — a lighter, more customizable interface that prioritizes smooth layouts and fast fills over the density of Axiom’s professional toolset.
That positioning — faster and lighter without sacrificing the core feature set serious traders expect — is part of why Terminal built a loyal user base well before the Pump.fun acquisition, and it’s the main reason the rebrand hasn’t meaningfully disrupted its user experience.
It’s easy to read “Padre got acquired and renamed” as a minor branding footnote. It isn’t. Pump.fun has spent 2026 aggressively consolidating the infrastructure layer underneath memecoin trading — not just the launch mechanism (the bonding curve itself), not just the secondary market (PumpSwap), but now the execution terminal traders actually use to interact with both. That’s vertical integration across the entire memecoin trading stack, from token creation through to the interface traders use to buy and sell.
For Terminal users, the practical upside is tighter integration with Pump.fun-native tools — Trenches’ bonding-curve tracking is a clear example, and it’s reasonable to expect more Pump.fun-specific features to get built directly into Terminal over time given the shared ownership. For PUMP token holders, Terminal’s trading fees are now explicitly one of the revenue streams funding PUMP’s buyback-and-burn mechanism, which means Terminal’s growth as a product has a direct line to PUMP’s tokenomics — a connection worth understanding if you hold both.
Several independent referral pages currently advertise cashback offers on Terminal trading fees, with rates cited as high as 35–45% depending on the specific referral program. These are third-party affiliate arrangements rather than a single official platform-wide rate, so treat any specific percentage as program-specific rather than universal, and confirm the current terms directly on whichever referral link you use before assuming a rate applies.
Save Fees and Earn Cashback on Terminal, today.
Because Trenches is arguably Terminal’s most distinctive feature relative to generic DEX aggregators, it’s worth walking through how it actually organizes information for traders working the earliest stages of the memecoin lifecycle.
Every token that launches through a bonding-curve mechanism — the model Pump.fun popularized, where a token’s price rises algorithmically as more people buy in, before “graduating” to a fully liquid market once it crosses a funding threshold — passes through predictable stages. Trenches maps directly onto that lifecycle:
New tokens are the earliest-stage listings, freshly launched and still climbing the bonding curve. This is the highest-risk, highest-reward stage: most tokens here will never graduate, but the ones that do can offer the steepest early entries.
Almost Bonded tokens are approaching the end of the curve, and this stage is frequently where trading activity spikes hardest, as momentum traders pile in ahead of graduation in anticipation of the liquidity event that follows.
Recently Bonded tokens have just crossed into a fully liquid secondary market, meaning slippage and thin order books matter less, but the “easy” early-curve upside has already played out.
Each token card in Trenches displays a customizable set of metrics — traders can toggle which data points show up based on their own strategy, whether that’s holder concentration, dev wallet behavior, liquidity depth, or transaction velocity. The dev-signal tracking in particular is aimed at one of the most common memecoin failure patterns: a developer wallet quietly accumulating or dumping supply in a way that isn’t visible from price action alone.
Not every trader needs every feature Terminal offers, so it’s worth being specific about where the platform earns its keep versus where a simpler tool might suffice.
High-frequency bonding-curve traders get the most out of Terminal’s core value proposition — the ~300ms execution window and Trenches’ staged tracking are built specifically for catching new launches and migrations before slower tools even register them.
Multi-chain traders benefit from not having to run four separate wallet setups and four separate charting tools across Solana, Ethereum, Base, and BNB Chain — Terminal’s unified portfolio view alone saves meaningful time and reduces the chance of missing a position that’s quietly moving on a chain you’re not actively watching.
Wallet-tracking and copy-trading users get real value from following specific high-performing wallets in real time rather than manually checking a block explorer every few minutes — though it’s worth noting that copy-trading a wallet doesn’t guarantee it continues performing the way its historical track record suggests.
Casual, buy-and-hold-style crypto users are probably not the target audience here. Terminal is built for active, hands-on trading with fast entries and exits — its entire feature set (automated stops, MEV protection, rug detection tuned for new launches) is oriented around a trading style, not a long-term holding strategy. If that’s not your approach, a simpler DEX interface or a centralized exchange may be a better fit.
It’s worth zooming out briefly, because the “memecoin trading terminal” category itself has become genuinely competitive in 2026, and understanding where Terminal sits in that landscape helps clarify why the Pump.fun acquisition was strategically significant.
Tools like Axiom, Photon, and BullX all compete in roughly the same space — fast execution, bonding-curve tracking, MEV protection, and multi-chain support, aimed at the same base of active memecoin traders. The differentiation between them tends to come down to execution speed, fee structure, chain coverage, and how tightly integrated each tool is with the launchpads where memecoins actually originate. That last point is exactly where Terminal’s position changed most significantly post-acquisition: no competing terminal has direct corporate ownership ties to Pump.fun itself, the platform responsible for the largest share of new memecoin launches on Solana. That’s a structural advantage that’s difficult for a purely third-party terminal to replicate, regardless of how good its execution engine is.
Whether that translates into a lasting competitive edge will depend on how deeply Pump.fun continues integrating Terminal into its own product roadmap going forward — but as of 2026, it’s the clearest example of a memecoin terminal being pulled directly into a launchpad’s owned infrastructure rather than remaining an independent third party.
Terminal’s non-custodial, client-side key encryption is a real security advantage, but it also means the responsibility for key safety sits entirely with the trader — there’s no customer support recovery path if a password is lost, the same trade-off inherent to any true self-custody tool. A few practices matter regardless of which terminal you’re using:
It’s worth spending a bit more time on Terminal’s automated order types, because their value is easy to underrate if you’re used to trading in slower-moving markets. In equities or even in large-cap crypto, a limit order or trailing stop is a convenience — a way to avoid staring at a screen all day. In memecoin trading, automated exits function closer to a survival mechanism.
Thin-liquidity tokens can move 30%, 50%, or more in the time it takes to switch browser tabs. A trader manually watching a chart is, in practice, reacting after the move has already happened rather than during it. Terminal’s built-in take-profit and trailing-stop automation closes that gap by executing the moment a price target is hit, without requiring the trader’s attention at that exact second. Trailing stops in particular are worth understanding well: rather than locking in a single fixed exit price, a trailing stop moves upward as the token’s price rises, locking in gains while still leaving room for further upside — and only triggers a sell once price pulls back by a set percentage from its peak. For a category where the difference between “took profit near the top” and “watched it round-trip back to zero” often comes down to a handful of seconds, that automation isn’t a nice-to-have. It’s arguably the single feature most responsible for separating traders who consistently bank gains from traders who consistently watch paper profits evaporate.
None of this replaces judgment — setting a trailing stop percentage too tight can shake you out of a position on normal volatility, and setting it too loose defeats the purpose of having one at all. But having the mechanism available, built directly into the same interface you’re already trading from, removes one of the more common points of failure in fast-moving memecoin trades: the gap between deciding to sell and actually executing that decision in time.
Matching the standard ArchitecTrade image workflow, here’s where visuals add the most value in this piece:
Header image, right below the title. A clean graphic showing the Padre-to-Terminal rebrand — split-screen or before/after style logo treatment. Best generated via Ideogram, styled to match your existing brand visuals.
Below “The Big Update” section. A simple timeline graphic marking the October 24, 2025 snapshot and December 30, 2025 claim deadline. Build this yourself in Canva rather than sourcing externally, since it’s specific factual content you want full control over.
Below “Core Features, Broken Down.” A screenshot of the actual Terminal interface, ideally showing the order panel or portfolio view. This should come from your own account — a real screenshot builds far more trust here than any generated graphic, since this section is your feature-by-feature walkthrough and readers will want to see the real thing.
Within “Trenches in More Depth.” A screenshot of the Trenches view itself, showing the New/Almost Bonded/Recently Bonded columns. Again, your own account — this is the single most valuable screenshot in the entire article since Trenches is Terminal’s most distinctive feature.
Below “Terminal in the Broader Memecoin Terminal Landscape.” An optional comparison graphic (simple table or icon row) showing Terminal alongside Axiom and Photon by category — not by exact fee numbers, since those change often, but by general positioning (speed, structure, chain coverage). Build in Canva.
Near the FAQ section. Optional — a simple icon-based FAQ graphic isn’t necessary here; this section performs better as clean text for both SEO crawlability and mobile readability.
Given how much churn happens across the memecoin space, it’s worth spending a bit more time on the token transition specifically, since it’s the part of this story most likely to generate reader questions. If you held PADRE prior to the acquisition, the token’s original utility on the platform is gone — it no longer grants trading benefits, fee discounts, or any other function within Terminal itself. The stated path for legacy holders was a wallet-address submission tied to the October 24, 2025 snapshot, converting eligible PADRE holdings into PUMP tokens by the December 30, 2025 deadline.
If you’re reading this well after that window closed and never submitted a claim, the honest answer is that your options are limited — this is precisely the kind of “the window closes whether or not you acted” scenario worth internalizing for future token migrations and snapshot events generally. The practical lesson for any active memecoin or DeFi trader: when a platform you use gets acquired or announces a token migration, treat the claim window as a hard deadline, not a soft one, and act inside it rather than assuming there will be a grace period. There typically isn’t.
Is Padre and Terminal the same platform? Yes. Terminal is the new name for Padre following its acquisition by Pump.fun in late 2025. The underlying product, wallet architecture, and trading interface are the same; only the name, ownership, and PADRE token’s utility changed.
What happened to the PADRE token? PADRE lost its platform utility following the Pump.fun acquisition. Holders were required to submit their Solana wallet addresses following an October 24, 2025 snapshot to claim PUMP tokens, with a claim deadline of December 30, 2025.
Which chains does Terminal support? As of 2026, Terminal supports Solana, Ethereum, Base, and BNB Chain from a single interface.
Is Terminal safe to use? Terminal is non-custodial, meaning private keys are encrypted client-side and never accessible to the team. That’s a meaningful security advantage over custodial platforms, but it also means you’re solely responsible for key security — there’s no account recovery if credentials are lost. Standard security practices (official links only, dedicated trading wallets, periodic approval revocation) still apply.
Why did Pump.fun acquire Padre? The acquisition extended Pump.fun’s control over the full memecoin trading stack — from token creation (the bonding curve) through secondary trading (PumpSwap) to the execution terminal traders use directly (Terminal). It also added a third revenue stream feeding into PUMP’s buyback-and-burn tokenomics program.
Terminal remains, functionally, one of the faster and more accessible multi-chain memecoin trading terminals available in 2026 — the rebrand didn’t change the core product, and if anything, the Pump.fun acquisition points toward tighter integration with the platform where most Solana memecoin activity actually originates. If you were a Padre user before the acquisition, the transition to Terminal should feel seamless. If you’re new to the platform, the combination of execution speed, built-in risk tooling, and multi-chain support makes it a reasonable default terminal for active memecoin trading — provided you go in treating every position as fully speculative capital, consistent with the risk profile of the meme coin category as a whole.
This article is for informational purposes only and does not constitute financial advice. Meme coin trading is highly speculative and carries substantial risk of loss. Always verify official platform links directly and do your own research (DYOR) before trading.
Terminal (Formerly Padre): The Complete 2026 Guide to the Trading Platform Now Owned by Pump fun was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
In this 2-part bonus guide on the features and troubleshooting once you ROFLize an app, the first part covered in detail the marketplace, secrets, and persistent storage. Let’s continue.
You will remember that we learned about secrets for confidential values. But an app may also consist of containers that need to access non-sensitive values and configurations. API endpoints, contract addresses, feature flags, etc are some examples of information that do not have or need any confidential attributes. This is when we use public variables. They are basically arbitrary key-value pairs that are exposed to containers as environment variables.
You can manage these public variables using the Oasis CLI. Take this example where we create a public variable called API_URL.
echo -n "https://api.example.com" | oasis rofl public-var set API_URL -
You will notice that this command only updates the local app manifest file. The public variable, however, is not yet propagated to the app. As a result, you will be able to easily configure as many public variables as you want without having to constantly update the on-chain app configuration.
Once the required public variables are created, you can update all of them in the on-chain configuration using the usual command.
oasis rofl update
The Oasis CLI documentation is useful if you need to consult comprehensive public variable management commands, including importing from .env files, removing public variables, and other advanced features.
Now, inside the containers, the public variables can be passed via environment variables. This is possible because each public variable is automatically exposed in the Compose environment and can be used in the Compose file.
services:
test:
image: docker.io/library/alpine:3.21.2@sha256:f3240395711384fc3c07daa46cbc8d73aa5ba25ad1deb97424992760f8cb2b94
command: echo "API URL is $API_URL"
environment:
- API_URL=${API_URL}
Before proceeding in this section, let’s familiarize ourselves with the metadata in the yaml root, consisting of these valid fields.
App Resources (resources)
Each containerized app running in ROFL needs pre-defined resources such as the number of assigned vCPUs, amount of memory, storage requirements, GPUs, etc, for its execution. In the app manifest file, these will be headed under resources.
resources:
memory: 512
cpus: 1
storage:
kind: disk-persistent
size: 512
If you decide to change the requested resources, it will result in the creation of a different enclave identity for the app. Then you will have to update the policy accordingly.
Let’s now see what these resources signify.
The size field defines the amount of storage to provision in megabytes.
Artifacts (artifacts)
This configures locations of artifacts used during the ROFL build process with builder, firmware, kernel, stage2, container.runtime, and container.compose as supported fields. If any fields are left unspecified, they will use the default artifacts from the CLI. For containerized apps, container.compose points to the Compose file included in the ROFL bundle.
artifacts:
container:
compose: compose.yaml
Deployments (deployments)
This contains ROFL deployments on specific networks.
The deployment you have defined will show as deployment_name.
Deployment artifacts are optional and merged field by field on top of global artifacts.
deployments:
testnet:
network: testnet
paratime: sapphire
artifacts:
container:
compose: compose.testnet.yaml
There are four components to policy under which your app will spin up.
You can choose one or multiple conditions in a nested format by using and and or operators.
policy.yaml
endorsements:
- and:
- provider: oasis1qp2ens0hsp7gh23wajxa4hpetkdek3swyyulyrmz
- or:
- provider_instance_admin: oasis1qrk58a6j2qn065m6p06jgjyt032f7qucy5wqeqpt
- provider_instance_admin: oasis1qqcd0qyda6gtwdrfcqawv3s8cr2kupzw9v967au6
This example indicates that the app can be run only on the specified provider, and on machines owned by either of the two admin addresses.
The final piece of this section is machines, where the specific app deployment takes place. If you remember the oasis rofl deploy tutorial, it creates a new default machine if there is no existing machine. If there is one, then the app is redeployed here.
Each containerized app running in ROFL runs a special daemon called rofl-appd. It exposes additional functions via a simple HTTP REST API. To enable easier access isolation, the API is exposed via a UNIX socket located at /run/rofl-appd.sock.
Let’s consider this example where we have used the short syntax for Compose volumes.
services:
mycontainer:
# ... other details omitted ...
volumes:
- /run/rofl-appd.sock:/run/rofl-appd.sock
ROFL clients
For your ROFL app, it is strongly recommended that you follow the steps to bind the UNIX socket by accessing the ROFL REST API through one of the ROFL clients. You can choose any one of the following languages.
Note: Although the communication with rofl-appd is through UNIX sockets, the REST service still uses the HTTP protocol. In our examples, we will be using the http://localhost/<endpoint_path> format throughout. You are free to provide any name instead of a hostname.
Endpoints
App Identifier is where the endpoint is used to retrieve the app ID.
Endpoint:/rofl/v1/app/id ( GET)
Example response:
rofl1qqn9xndja7e2pnxhttktmecvwzz0yqwxsquqyxdf
Key Generation
Here, each registered app automatically gets access to a decentralized on-chain key management system. Now, the keys can only be generated inside properly attested app instances. They remain unchanged even if the app is deployed elsewhere, or even if its state is erased.
Endpoint:/rofl/v1/keys/generate ( POST)
Example request:
Login{
"key_id": "demo key",
"kind": "secp256k1"
}The generated key is returned as a hexadecimal string.
Example response:
{
"key": "a54027bff15a8726b6d9f65383bff20db51c6f3ac5497143a8412a7f16dfdda9"
}Authenticated Transaction Submission
This is important if your app is registered with a different chain instead of Oasis. It enables your ROFL app to submit authenticated transactions to that chain. As these transactions are signed by an endorsed ephemeral key, they get automatically authenticated.
This also helps to easily authenticate the transaction origin in smart contracts by simply invoking an appropriate subcall.
Subcall.roflEnsureAuthorizedOrigin(roflAppID);
Endpoint: /rofl/v1/tx/sign-submit (POST)
Example:
{
"encrypt": true,
"tx": {
"kind": "eth",
"data": {
"gas_limit": 200000,
"to": "1234845aaB7b6CD88c7fAd9E9E1cf07638805b20",
"value": "0",
"data": "dae1ee1f00000000000000000000000000000000000000000000000000002695a9e649b2"
}
}
}Let’s decipher the fields before proceeding further.
tx describes the transaction content. Different transaction kinds are supported as defined by the kind field.
Ethereum-compatible calls ( eth) use standard fields such as gas_limit, to, value, and data.
For gas_limit, you can input a JSON number (as used in the example), a decimal string, or a 0x-prefixed hex string. There should not be any whitespace, and irrespective of the input, it will be interpreted as a non-negative 64-bit integer.
For value, you can input a JSON number up to 2^64 - 1, a decimal string, or a 0x-prefixed hex string. There should not be any whitespace in the string forms, and the value must represent a non-negative integer up to 256 bits.
For hex-encoded fields such as to and data, you can input strings with or without a leading 0x prefix, but there should not be any whitespace or prefix-only input. Empty strings are accepted for contract creation or empty calldata, e.g. to: "" or data: "". If you are providing input for the to field, it must decode to exactly 20 bytes representing an Ethereum address.
Alternately, Oasis SDK calls ( std) support CBOR-serialized hex-encoded Transactions to be specified.
encrypt is a boolean flag specifying whether the transaction should be encrypted. This field is true by default. When an ephemeral key is being used, the encryption is handled transparently for the caller, and any response is first decrypted before being passed on.
Now, as the outcome of the example request, the example response inside data is generated as a JSON response containing a CBOR-serialized hex-encoded call result that you will need to deserialize.
If the call result is successful:
{
"data": "a1626f6b40"
}It deserializes as {"ok": ''}.
If it is unsuccessful:
{
"data": "a1646661696ca364636f646508666d6f64756c656365766d676d6573736167657272657665727465643a20614a416f4c773d3d"
}It deserializes as {"fail": {"code": 8, "module": "evm", "message": "reverted: aJAoLw=="}}.
Replica Metadata
This allows apps to publish arbitrary key-value pairs included in the on-chain ROFL replica registration and automatically namespaced with net.oasis.app.
Endpoint: /rofl/v1/metadata (GET)
Example response:
{
"key_fingerprint": "a54027bff15a8726",
"version": "1.0.0"
}Endpoint: /rofl/v1/metadata (POST)
Example request:
{
"key_fingerprint": "a54027bff15a8726",
"version": "1.0.0"
}The parameters for metadata validation are the number of pairs, key size, and value size.
Endpoint: /rofl/v1/metadata (PUT)
Example request:
{
"version": "1.0.1"
}Endpoint: /rofl/v1/metadata (DELETE)
Example request:
["version", "key_fingerprint"]
Whenever you use Set, Upsert, or Delete Metadata, any change in the metadata triggers a registration refresh.
Query
This runs arbitrary query methods defined in the Oasis Runtime SDK module and returns the result.
Endpoint: /rofl/v1/query (POST)
Example request:
{
"method": "rofl.App",
"args": "a16269645500694cb01f85408d624ea267f657bf285787a61db3"
}Here, method refers to the internal name of query methods; in our example, it is rofl.App. You will recognize query methods by the #[handler(query = "...")] annotation in the Oasis Runtime SDK source.
args represent query parameters for the method serialized as CBOR and hex-encoded.
Example response:
{"data":"a76269645500ffe981cceff2d759d19fa926faebb7d90c0a59a56373656b582056c6d4841fa5ad24ad761088cb7053ad312ef13f3c2f405640fdba2bde4c14386561646d696e55007814f3d954f41b6459eb9e4bc8fbc6767ece5aa9657374616b658249056bc75e2d631000004066706f6c696379a56466656573026671756f746573a263696173f663706373a363746478a173616c6c6f7765645f7464785f6d6f64756c657380737463625f76616c69646974795f706572696f64181e781e6d696e5f7463625f6576616c756174696f6e5f646174615f6e756d6265721268656e636c6176657382a2696d725f7369676e6572582000000000000000000000000000000000000000000000000000000000000000006a6d725f656e636c6176655820bd4844a79a12ba365e890ddeaebbc4e4292797c7d956b42c2e25e4aefce3b124a2696d725f7369676e6572582000000000000000000000000000000000000000000000000000000000000000006a6d725f656e636c6176655820412c94a9baa0949f718dbba41ab89c38ea5c320345bba36b07e2ef857ffe2fb96c656e646f7273656d656e747381a163616e79a06e6d61785f65787069726174696f6e036773656372657473a26a50494e4154415f4a5754590327a462706b58207f88546291174f854a8ce2eb4bbfc8e62e40d60cdae2d600920a766d3006bf6c646e616d65581aad0460d0f742ad697b6d7c8462cc2b153deeb051a791553ef52b656e6f6e63654f8cbbe6631910d9a702e49bd30ee8f46576616c75655902c1352d823e54f75c846579066e2c1a750387f0630e3f29dba5524984712883bb33371ff017e507ae432b135312af64bfb85f3b17def05b2ac2744256f5accf1a26b29cd8cd412f08bfc9204f9bfa670b2d65972cfc4a8d4e2074402f21c18dfe554b1f0a8a731c077699f741807b3a4047ef4dc570958b8b46111a445259e93c9b92a5f72a23d32cbbef875efe586a8ddda38f1fa286d19b369a2022c3eae1cdbf6f6de4dc055bbab36a2c4830f8e2c64437f5f878f419e21f3a4c0f13c47b63697668b34722eaa61bdffa12e82be6d0266a41590254c9d70e9237475f6115c2867065c49afa8032acdfe0bc5dc671ef48ebc58d893937659243479e2eaa38815cd8665541e4c7e40349524cda15f2d410cba100ee27f0a59dc63534f7cff2444b57c7b74060cf8c3e21e1590b597384a89a463d6bb4a52fc52a4592889448a8f8e0c02fef1689c1efea58ddc08783f6d22d7a908cdf2a45bc46a79a3b73ff5f13bbbf7219973a7382eee84b3b4d48036b5e87fb24223e6387a3e37f9c1ac9722534adfef0201ec13db2e70fe9cd0336f020e50b59d7d32951378f568a4ef3a8117386ff0f1ba4b7d33dcf913daa696a6a7d64d20220b0e5eec994ea56aa9c01f56f5e12bf7d555b3f4a218ddbd8ae1586d5cb1e76802c90e26472b233686e8449284829378163acd77d1b65d4953a76cc497584580c1a5ac4fe6d97fd818fa53c2eb43c6f1b7a79211ef57f24036b1f8ed37f4c3d36873bbbd876769a5fde17add6926317afc96c9707e10b150735c63877ffd6475b1a27b6dd108940f0097375e422b1d308c6c8a0a83847368f5760778c54f2a70b44f9365c55c4b5d69341cad62d6fdb11aa25a9e26b4977adebd65718042bda1cbbf988298d293547107c2f5899352188179bc4d22febc66e8e351885498e707dee583d052c0b7c13f930e4529b59c36c20ee3ee6d29d1a3e2bb65bd489b7206cd45d2ae046f1e147d6407c166e494e465552415f4150495f4b45595899a462706b582074be2e227be81a5e35943ac1b79e238395b9bc367f7a0d1eed740c259ae23a37646e616d65581ee5190cda87688753f6f221890bfed8fe0e27b3ced4a9bc54537da1f4cd90656e6f6e63654fcf5411193abf4f4711f17179ea4b6f6576616c756558304675a29c8398bc94b5057063b4badeb9937a6e019ef7f8095d6b5a035106d4e8e7d710af9b6883848886481c1d180cbc686d65746164617461a7736e65742e6f617369732e726f666c2e6e616d656f76616c696461746f722d6167656e74756e65742e6f617369732e726f666c2e617574686f72782a4d61746576c5be204a656b6f766563203c6d617465767a406f6173697370726f746f636f6c2e6f72673e766e65742e6f617369732e726f666c2e6c6963656e73656a4170616368652d322e30766e65742e6f617369732e726f666c2e76657273696f6e65302e312e30776e65742e6f617369732e726f666c2e686f6d6570616765784f68747470733a2f2f6769746875622e636f6d2f6f6173697370726f746f636f6c2f6572632d383030342f626c6f622f6d61737465722f524541444d452e6d642376616c696461746f722d6167656e7478196e65742e6f617369732e726f666c2e7265706f7369746f7279782968747470733a2f2f6769746875622e636f6d2f6f6173697370726f746f636f6c2f6572632d38303034781a6e65742e6f617369732e726f666c2e6465736372697074696f6e787f4c697374656e7320746f2056616c69646174696f6e52657175657374206576656e7473206f6620746865204552432d383030342076616c69646174696f6e20726567697374727920616e642076616c696461746573207768657468657220746865206167656e7420697320706f776572656420627920524f464c205445452e"}Inside data, the JSON response contains the CBOR-serialized method's return value in hex format.
If you want to try other examples, you can check out the relevant section of the ROFL demo repository for querying with curl directly.
There is also a production-ready Python example at hand — in the ROFL-8004 implementation where the query endpoint is used to fetch various app on-chain metadata for registration in the ERC-8004 identity registry.
When you publish a port in your compose.yaml file, the ROFL proxy automatically makes your services accessible via public URLs. It also ensures the routed traffic is done correctly.
This uses TLS, which is terminated inside your ROFL enclave, maintaining confidentiality and integrity protection. As a result, even the provider cannot see or modify the traffic. Moreover, the default terminate-tls mode generates and configures a Let's Encrypt certificate in ROFL to authenticate your services.
To enable the proxy and expose a port from your container, you need to publish it in your compose.yaml file.
compose.yaml
services:
frontend:
image: docker.io/hashicorp/http-echo:latest
ports:
- "5678:5678" # Expose container port 5678 on host port 5678
After deploying your app, you can find the generated URL by running the usual command.
oasis rofl machine show
The output generated in this way will show a Proxy section with the public URL for each published port.
Proxy:
Domain: m602.test-proxy-b.rofl.app
Ports from compose file:
5678 (frontend): https://p5678.m602.test-proxy-b.rofl.app
Configuration
You can use the annotations in your compose.yaml file to configure the proxy behavior.
The general format of an annotation is net.oasis.proxy.ports.<published_port>.<setting>: <value>.
Here,<published_port> is the external port exposed in your compose.yaml, and <setting> indicates the specific proxy configuration like mode or custom_domain.
Example:
Here I will configure port 80 to use the default terminate-tls mode with a custom domain and port 8080 to use TCP passthrough.
compose.yaml
services:
myservice:
image: docker.io/my/service:latest
ports:
- "80:80"
- "8080:8080"
annotations:
net.oasis.proxy.ports.80.custom_domain: mydomain.com
net.oasis.proxy.ports.8080.mode: passthrough
This shows:
Annotation Reference
net.oasis.proxy.ports.<published_port>.mode defines how the proxy should handle connections for the specified port.
net.oasis.proxy.ports.<published_port>.custom_domain assigns a custom domain name to the published port.
Here, when using the default terminate-tls mode, you need to use special configuration for your custom domain to route through the proxy. Once the app is deployed, you can use Oasis CLI for instructions to configure A and TXT records in your DNS.
oasis rofl machine show
Proxy:
Domain: m897.opf-testnet-rofl-25.rofl.app
Ports from compose file:
5678 (frontend): https://demo.rofl.build
* Point the A record of your domain to: 131.153.241.25
* Add a TXT record to your domain:
oasis-rofl-verification=4SKHCn4E2SNDB5tXayQeHZsvH/+kJSNGuQaTAPepYJc=
If you choose to go with passthrough mode, the proxy will not terminate TLS and your app will then need to handle it directly. Also, here the custom_domain setting is not needed, so you can configure the domain directly to the ROFL instance's address.
For the ignore mode, the port isn't published, so the custom_domain setting has no effect.
Here I will cover some common errors and the troubleshooting process.
Compilation
Sometimes you will see an error message if the aes and ssse3 compiler flags are not enabled during compilation of your SGX and TDX-raw ROFL.
error: The following target_feature flags must be set: +aes,+ssse3.
--> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/deoxysii-0.2.4/src/lib.rs:26:1
|
26 | compile_error!("The following target_feature flags must be set: +aes,+ssse3.");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The workaround is to add default flags to your .cargo/config.toml file.
[build]
rustflags = ["-C", "target-feature=+aes,+ssse3"]
rustdocflags = ["-C", "target-feature=+aes,+ssse3"]
[test]
rustflags = ["-C", "target-feature=+aes,+ssse3"]
rustdocflags = ["-C", "target-feature=+aes,+ssse3"]
Compose file
A couple of errors are possible here due to an upstream podman compose bug.
The first is when environment variables defined are not considered.
services:
oracle:
platform: linux/amd64
environment:
CONTRACT_ADDRESS: 0x5FbDB2315678afecb367f032d93F642f64180aa3
entrypoint: /bin/sh -c 'python main.py $${CONTRACT_ADDRESS}'
In this type of error, the CONTRACT_ADDRESS field will return as empty in ROFL. You need to inject the variable value directly inside entrypoint as a workaround.
services:
oracle:
platform: linux/amd64
entrypoint: /bin/sh -c 'python main.py 0x5FbDB2315678afecb367f032d93F642f64180aa3'
The other type of error that may occur is when depends_on is ignored.
services:
contracts:
image: "ghcr.io/foundry-rs/foundry:latest"
platform: linux/amd64
volumes:
- ./contracts:/contracts
entrypoint: /bin/sh -c 'cd contracts && forge create'
oracle:
platform: linux/amd64
entrypoint: /bin/sh -c 'python main.py'
restart: on-failure
depends_on:
contracts:
condition: service_completed_successfully
In this type of error, instead of oracle spinning up once the contracts service successfully deploys the contracts and finishes, they start in parallel by ignoring the depends_on command.
There is no immediate workaround as of now. You can try to implement customized logic in your oracle service to crash it, and then trigger the restart mechanism and try again.
appd
If you encounter the 422 Unprocessable Entity error, when the provided request couldn't be decoded, you need to ensure all the required fields are present and correctly formatted in accordance with the appd REST API section described above.
ROFL Proxy URL is not working
Sometimes the app might be using outdated artifacts, which will result in the proxy URL returned by oasis rofl machine show being inaccessible. This is easily fixed by updating to the latest Oasis CLI version. The next step is to run oasis rofl upgrade in your project directory to update the artifacts in your rofl.yaml file, and finally, rebuild and redeploy your app.
oasis rofl build
oasis rofl update
oasis rofl deploy
This concludes our 2-part bonus guide describing the various features for your ROFL app, and some common troubleshooting hacks. Looking forward to your feedback in the comments section.
For technical specs, APIs, architecture, and integration guides, the Oasis documentation is your starting point.
For direct support on specific issues, the Oasis engineering team is available in thedev-central channel on the official Discord.
Originally published at https://dev.to on August 14, 2026.
ROFLize an App: Bonus Guide to Features & Troubleshooting (Part 2) was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Bitcoin Magazine
Breez Drops New Bitcoin App Which Doubles As Wallet and Developer Toolkit
Bitcoin software provider Breez has released a new app it says will serve both everyday users and developers.
The product, dubbed Glow, is supposed to be an easy way to make Lightning transactions easier for everyday users, while also doubling as an open-source blueprint — a way to see exactly how easy it is to implement Bitcoin features using the SDK’s API — for builders.
Breez claims the app will help developers exploring Bitcoin see what’s possible by packaging in the features that are essential for any Bitcoin app to compete in its category.
Being open-source, developers can open up Glow’s codebase and see exactly how each of those features — such as passkey login, Lightning addresses or stablecoin transfers — work and use them for their own app, rather than building it from scratch.
For example, a developer building a social app doesn’t need to figure out how Lightning address or contacts should work — they can look at Glow’s code, see the API calls it makes, and replicate that in their own product with minimal effort.
Developers can fork Glow, rebrand it, and ship it as their own, according to Breez.
Because developers building on the SDK never take custody of user funds, Breez notes the regulatory footprint stays minimal — letting teams focus on product rather than compliance overhead.
The Glow app release comes after Breez announced it was working with Turnkey last month, a deal letting developers add non-custodial Bitcoin to apps running wallets from their own servers — solving a custody problem that has kept many of the largest consumer platforms from integrating Bitcoin at all.
According to the companies, keys now stay out of reach of the app’s servers, Breez, and Turnkey. The company’s backend holds a credential that defines what actions it can take, while authority to move funds rests with the user.
The deal positions some of the world’s largest consumer apps to add non-custodial Bitcoin without rebuilding their backend architecture or taking custody of user funds.
This post Breez Drops New Bitcoin App Which Doubles As Wallet and Developer Toolkit first appeared on Bitcoin Magazine and is written by Mathew Di Salvo.
Bitcoin Magazine
NYSE-Listed AI Company Taps Lightning Network to Pay Employees In Bitcoin
Publicly traded AI operating system Vida Global (NYSE American: VIDA) has said it has started paying employees in Bitcoin using the Lightning network — but in a way where the company does not have the leading crypto on its balance sheet.
The Austin, Texas-based company said Thursday that after a worker in Argentina asked to be paid in Bitcoin, the firm tapped Bitcoin infrastructure company Voltage to make the transaction.
But the company is not keeping Bitcoin on its books: it simply sends the cash amount via Voltage’s platform, the employees receive payment in Bitcoin, and Vida’s balance sheet remains in dollars.
“Vida has a global team, including team members in Argentina who prefer to be paid in Bitcoin because of challenges with their local currency,” Vida CEO Lyle Pratt said.
“Voltage facilitates the Bitcoin payments, and we settle the balance in U.S. dollars at the end of the month, just like a standard vendor invoice. It has made offering Bitcoin payments remarkably simple for both our team and our finance operations.”
Pratt added the setup meets employee needs without adding crypto complexity to accounting.
Voltage CEO Graham Krizek said it was solving a mismatch between “global by default” AI companies and payment rails that haven’t kept up.
“Their team members get paid in seconds in the money they actually want, and their finance team never touches crypto,” he said. “When a public company runs part of its team compensation on Bitcoin rails and the books stay boring, that’s the point.”
Lightning is another network that skirts transactions around the main chain, cutting costs and increasing speed — originally designed so people could use Bitcoin for daily purchases.
Bitcoin maxis like Twitter co-founder Jack Dorsey have since integrated the network into their businesses, payments platform, Cash App and his PoS terminals, Square.
This post NYSE-Listed AI Company Taps Lightning Network to Pay Employees In Bitcoin first appeared on Bitcoin Magazine and is written by Mathew Di Salvo.
