From 17f74b1fbb9415133cc1b021dc4531a9810d4e57 Mon Sep 17 00:00:00 2001 From: Elliot Date: Tue, 4 Aug 2026 10:13:32 -0500 Subject: [PATCH 1/5] Distinguish OpenZeppelin Relayer from the managed Stellar Channels service The Tools index and the OpenZeppelin Relayer page both described the Relayer as "also known as Stellar Channels Service" and as managed infrastructure. That presents two things as one product when their operational contracts differ: the Relayer is an open source (AGPL-3.0) framework you can run yourself, in which case you hold the signing keys and fund the accounts that pay fees, while Stellar Channels is the service OpenZeppelin operates on top of it, running the channel account pool and covering fees under a fair use policy. Rewrites both blurbs to separate the framework from the managed service, and adds a note that the examples on the Relayer page authenticate against the managed Channels endpoints rather than a self-hosted relayer. Closes #2707 Co-Authored-By: Claude Opus 5 (1M context) --- docs/tools/README.mdx | 2 +- docs/tools/openzeppelin-relayer.mdx | 12 ++++++++++-- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/docs/tools/README.mdx b/docs/tools/README.mdx index eb9364742c..0165000456 100644 --- a/docs/tools/README.mdx +++ b/docs/tools/README.mdx @@ -29,7 +29,7 @@ Quickstart is a local Stellar network environment (node) that allows developers ### [OpenZeppelin Relayer](./openzeppelin-relayer.mdx) -OpenZeppelin Relayer, also known as Stellar Channels Service, is a managed infrastructure for submitting Stellar Soroban transactions with automatic parallel processing and fee management. The service handles all the complexity of transaction submission, allowing you to focus on building your application. +OpenZeppelin Relayer is an open source framework for submitting Stellar transactions, with automatic parallel processing and fee management. You can run your own instance, or you can use [Stellar Channels](https://docs.openzeppelin.com/relayer/1.3.x/guides/stellar-channels-guide), the managed service OpenZeppelin operates on top of the Relayer, where OpenZeppelin runs the pool of channel accounts and covers the fees for you. ### [OpenZeppelin Contracts](./openzeppelin-contracts.mdx) diff --git a/docs/tools/openzeppelin-relayer.mdx b/docs/tools/openzeppelin-relayer.mdx index e56daf8d70..7f44fc223e 100644 --- a/docs/tools/openzeppelin-relayer.mdx +++ b/docs/tools/openzeppelin-relayer.mdx @@ -1,13 +1,21 @@ --- title: OpenZeppelin Relayer -description: OpenZeppelin Relayer is a service that provides infrastructure to relay transactions to the Stellar network. +description: OpenZeppelin Relayer is an open source framework for submitting transactions to the Stellar network, and Stellar Channels is the managed service OpenZeppelin runs on top of it. sidebar_label: OpenZeppelin Relayer sidebar_position: 43 --- Launchtube, which served as an experimental service for fee sponsorship and contract invocations, has been instrumental in early-stage deployments and developer experimentation. However, while functional for testing and early use cases, Launchtube does not have the maturity, scalability and auditing as OpenZeppelin’s Relayer service, which is why the Stellar Development Foundation is discontinuing the Launchtube service and provides the Relayer service as a replacement. -OpenZeppelin Relayer, also known as [Stellar Channels Service](https://docs.openzeppelin.com/relayer/1.3.x/guides/stellar-channels-guide), is a managed infrastructure for submitting Stellar Soroban transactions with automatic parallel processing and fee management. The service handles all the complexity of transaction submission, allowing you to focus on building your application. +OpenZeppelin Relayer is an open source (AGPL-3.0) framework for submitting Stellar transactions, including Soroban contract invocations, with automatic parallel processing and fee management. If you [run your own instance](https://github.com/OpenZeppelin/openzeppelin-relayer), you hold the signing keys and you fund the accounts that pay the fees. + +[Stellar Channels](https://docs.openzeppelin.com/relayer/1.3.x/guides/stellar-channels-guide) is the managed service OpenZeppelin operates on top of the Relayer. There are no servers, relayers, or channel accounts for you to configure, because OpenZeppelin runs the pool of channel accounts and covers the fees, subject to a fair use policy. + +:::note + +The examples on this page use the managed Channels service, so they authenticate with a Channels API key rather than talking to a relayer you run yourself. + +::: ## OpenZeppelin Relayer Status From 894ffb92956e3cd7fca281e7fd713e9615858917 Mon Sep 17 00:00:00 2001 From: Elliot Date: Tue, 4 Aug 2026 10:25:42 -0500 Subject: [PATCH 2/5] Name the managed service as Channels throughout the Relayer page Review feedback: the two blurbs were fixed, but the rest of the page still called managed Channels resources "Relayer" resources. The status section pointed at status.channels.openzeppelin.com under an "OpenZeppelin Relayer Status" heading, both tutorials called the hosted endpoint the "Relayer service endpoint", and the Launchtube paragraph named the Relayer as the replacement service when the hosted replacement is Channels. Renames those prose references to Channels and reserves "Relayer" for the underlying framework, the plugin package, and the upstream repo link. Code blocks are untouched. Co-Authored-By: Claude Opus 5 (1M context) --- docs/tools/openzeppelin-relayer.mdx | 44 ++++++++++++++--------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/docs/tools/openzeppelin-relayer.mdx b/docs/tools/openzeppelin-relayer.mdx index 7f44fc223e..f7d88cf52f 100644 --- a/docs/tools/openzeppelin-relayer.mdx +++ b/docs/tools/openzeppelin-relayer.mdx @@ -5,7 +5,7 @@ sidebar_label: OpenZeppelin Relayer sidebar_position: 43 --- -Launchtube, which served as an experimental service for fee sponsorship and contract invocations, has been instrumental in early-stage deployments and developer experimentation. However, while functional for testing and early use cases, Launchtube does not have the maturity, scalability and auditing as OpenZeppelin’s Relayer service, which is why the Stellar Development Foundation is discontinuing the Launchtube service and provides the Relayer service as a replacement. +Launchtube, which served as an experimental service for fee sponsorship and contract invocations, has been instrumental in early-stage deployments and developer experimentation. However, while functional for testing and early use cases, Launchtube does not have the maturity, scalability and auditing as OpenZeppelin’s Relayer, which is why the Stellar Development Foundation is discontinuing the Launchtube service and provides the managed Stellar Channels service as a replacement. OpenZeppelin Relayer is an open source (AGPL-3.0) framework for submitting Stellar transactions, including Soroban contract invocations, with automatic parallel processing and fee management. If you [run your own instance](https://github.com/OpenZeppelin/openzeppelin-relayer), you hold the signing keys and you fund the accounts that pay the fees. @@ -17,15 +17,15 @@ The examples on this page use the managed Channels service, so they authenticate ::: -## OpenZeppelin Relayer Status +## Stellar Channels status -To see live status of the OpenZeppelin relayer, please visit this [Status] page: https://status.channels.openzeppelin.com/. +To see the live status of Stellar Channels, please visit this [Status] page: https://status.channels.openzeppelin.com/. ## Smart contract invocation -Let’s create a simple application that submits a transaction, invoking a smart contract function, using Relayer. The application calls the Increment smart contract and returns the current counter value. +Let’s create a simple application that submits a transaction, invoking a smart contract function, using Channels. The application calls the Increment smart contract and returns the current counter value. -The application is based on the Next.js framework and has server side code and client side code. The OpenZeppelin Relayer SDK makes HTTPS-requests to OpenZeppelin endpoints, which will trigger CORS errors when run client side, but by using the SDK server side, CORS will not be an issue. +The application is based on the Next.js framework and has server side code and client side code. The `@openzeppelin/relayer-plugin-channels` SDK makes HTTPS-requests to OpenZeppelin endpoints, which will trigger CORS errors when run client side, but by using the SDK server side, CORS will not be an issue. ### Prerequisites @@ -33,11 +33,11 @@ This guide assumes you have deployed the Increment smart contract example code f ### Server Side -In this simple application we only have one function server side, and that’s a function calling a smart contract function, by submitting a transaction through Relayer. +In this simple application we only have one function server side, and that’s a function calling a smart contract function, by submitting a transaction through Channels. -#### 1. Initialize Relayer client +#### 1. Initialize the Channels client -First the two necessary SDKs are imported, and the Relayer client is initialized. In this tutorial we use testnet, so the Relayer service endpoint for testnet is used as the base URL. The API key can be generated [here](https://channels.openzeppelin.com/testnet/gen). +First the two necessary SDKs are imported, and the Channels client is initialized. In this tutorial we use testnet, so the Channels endpoint for testnet is used as the base URL. The API key can be generated [here](https://channels.openzeppelin.com/testnet/gen). ```js "use server"; @@ -79,9 +79,9 @@ const tx = new StellarSDK.TransactionBuilder(account, { #### 4. Simulate transaction and get XDRs -The final steps before we can submit the transaction to Relayer is to simulate the transaction, bundle the transaction and simulation, and extract the transaction’s function and auth XDRs. +The final steps before we can submit the transaction to Channels is to simulate the transaction, bundle the transaction and simulation, and extract the transaction’s function and auth XDRs. -We are extracting the function and auth from the assembled transaction, in XDR format, because that’s what we need to submit to Relayer. +We are extracting the function and auth from the assembled transaction, in XDR format, because that’s what we need to submit to Channels. ```js // Simulate to get auth entries @@ -93,9 +93,9 @@ const contractFunc = op.func.toXDR("base64"); const contractAuth = (op.auth ?? []).map((a) => a.toXDR("base64")); ``` -#### 5. Build Relayer request and submit it +#### 5. Build the Channels request and submit it -Now we have completed all necessary steps to submit a transaction to Relayer. First the request is built, and then the request is submitted to Relayer. +Now we have completed all necessary steps to submit a transaction to Channels. First the request is built, and then the request is submitted to Channels. ```typescript // Build request for Relayer @@ -133,7 +133,7 @@ return StellarSDK.scValToNative(txResponse.returnValue); #### 7. The complete code -The previous six steps contain all the functionality needed for invoking a smart contract function through Relayer. This is the complete code for the function that we will call from the client side (frontend): +The previous six steps contain all the functionality needed for invoking a smart contract function through Channels. This is the complete code for the function that we will call from the client side (frontend): ```js title="backend/index.tsx" "use server"; @@ -183,7 +183,7 @@ export const SendContractTransaction = async (sourceId: string, contractId: stri ### Client Side -The client side code shows a button on the page in the browser, and when clicked, the server side function will be called with the relevant parameters. When the function returns a value, the value is shown on the page instead of the button. The functionality is very simple, but serves well as an end-to-end example of submitting a transaction with Relayer. +The client side code shows a button on the page in the browser, and when clicked, the server side function will be called with the relevant parameters. When the function returns a value, the value is shown on the page instead of the button. The functionality is very simple, but serves well as an end-to-end example of submitting a transaction with Channels. #### 1. Call server side function @@ -282,17 +282,17 @@ export default function Home() { ## Account transfer -Let’s create another simple application, this application submits a transfer transaction, sending XLM tokens from one account to another, using Relayer. +Let’s create another simple application, this application submits a transfer transaction, sending XLM tokens from one account to another, using Channels. -The application is based on the Next.js framework and has server side code and client side code. The OpenZeppelin Relayer SDK makes HTTPS-requests to OpenZeppelin endpoints, which will trigger CORS errors when run client side, but by using the SDK server side, CORS will not be an issue. +The application is based on the Next.js framework and has server side code and client side code. The `@openzeppelin/relayer-plugin-channels` SDK makes HTTPS-requests to OpenZeppelin endpoints, which will trigger CORS errors when run client side, but by using the SDK server side, CORS will not be an issue. ### Server Side -In this simple application we only have one function server side, and that’s a function making a transfer of XLM tokens from one account to another, by submitting a transaction through Relayer. +In this simple application we only have one function server side, and that’s a function making a transfer of XLM tokens from one account to another, by submitting a transaction through Channels. -#### 1. Initialize Relayer client +#### 1. Initialize the Channels client -First the two necessary SDKs are imported, and the Relayer client is initialized. In this tutorial we use testnet, so the Relayer service endpoint for testnet is used as the base URL. The API key can be generated [here](https://channels.openzeppelin.com/testnet/gen). +First the two necessary SDKs are imported, and the Channels client is initialized. In this tutorial we use testnet, so the Channels endpoint for testnet is used as the base URL. The API key can be generated [here](https://channels.openzeppelin.com/testnet/gen). ```js "use server"; @@ -349,7 +349,7 @@ transaction.sign(sourceKeypair); #### 4. Submit the transaction -Now we have completed all necessary steps to submit the transaction to Relayer. The Relayer SDK function `submitTransaction()` takes the transaction in XDR-format as an argument. +Now we have completed all necessary steps to submit the transaction to Channels. The Channels client function `submitTransaction()` takes the transaction in XDR-format as an argument. ```js // Submit to Channels Relayer @@ -378,7 +378,7 @@ return response.hash; #### 6. The complete code -The previous five steps contain all the functionality needed for transferring XLM tokens from the source account to another account through Relayer. This is the complete code for the function that we will call from the client side (frontend): +The previous five steps contain all the functionality needed for transferring XLM tokens from the source account to another account through Channels. This is the complete code for the function that we will call from the client side (frontend): ```js title="backend/index.tsx" "use server"; @@ -437,7 +437,7 @@ export const SendTransaction = async (destinationPublicKey: string, amount: stri ### Client Side -The client side code shows a form with input fields for a transfer-to-address, and amount to transfer, on the page in the browser. When the form is filled out and submitted, the server side function will be called with the form values as parameters. When the function returns with the transaction hash, the hash is shown on the page instead of the form. The functionality is very simple, but serves well as an end-to-end example of submitting a token transfer transaction with Relayer. +The client side code shows a form with input fields for a transfer-to-address, and amount to transfer, on the page in the browser. When the form is filled out and submitted, the server side function will be called with the form values as parameters. When the function returns with the transaction hash, the hash is shown on the page instead of the form. The functionality is very simple, but serves well as an end-to-end example of submitting a token transfer transaction with Channels. #### 1. Call server side function From 989b7c7669cd5818f38191676e7a7c96c21a0e83 Mon Sep 17 00:00:00 2001 From: Elliot Date: Tue, 4 Aug 2026 10:42:57 -0500 Subject: [PATCH 3/5] Attribute Channels to OpenZeppelin and carry the fair use caveat to the index Review feedback. The Launchtube sentence read as though SDF provides the managed service, since "the Stellar Development Foundation" governs both verbs; OpenZeppelin operates Channels. The Tools index also promised covered fees without the fair use qualification the detail page carries. Co-Authored-By: Claude Opus 5 (1M context) --- docs/tools/README.mdx | 2 +- docs/tools/openzeppelin-relayer.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/tools/README.mdx b/docs/tools/README.mdx index 0165000456..5f537dff59 100644 --- a/docs/tools/README.mdx +++ b/docs/tools/README.mdx @@ -29,7 +29,7 @@ Quickstart is a local Stellar network environment (node) that allows developers ### [OpenZeppelin Relayer](./openzeppelin-relayer.mdx) -OpenZeppelin Relayer is an open source framework for submitting Stellar transactions, with automatic parallel processing and fee management. You can run your own instance, or you can use [Stellar Channels](https://docs.openzeppelin.com/relayer/1.3.x/guides/stellar-channels-guide), the managed service OpenZeppelin operates on top of the Relayer, where OpenZeppelin runs the pool of channel accounts and covers the fees for you. +OpenZeppelin Relayer is an open source framework for submitting Stellar transactions, with automatic parallel processing and fee management. You can run your own instance, or you can use [Stellar Channels](https://docs.openzeppelin.com/relayer/1.3.x/guides/stellar-channels-guide), the managed service OpenZeppelin operates on top of the Relayer, where OpenZeppelin runs the pool of channel accounts and covers the fees under a fair use policy. ### [OpenZeppelin Contracts](./openzeppelin-contracts.mdx) diff --git a/docs/tools/openzeppelin-relayer.mdx b/docs/tools/openzeppelin-relayer.mdx index f7d88cf52f..a1b47cf04f 100644 --- a/docs/tools/openzeppelin-relayer.mdx +++ b/docs/tools/openzeppelin-relayer.mdx @@ -5,7 +5,7 @@ sidebar_label: OpenZeppelin Relayer sidebar_position: 43 --- -Launchtube, which served as an experimental service for fee sponsorship and contract invocations, has been instrumental in early-stage deployments and developer experimentation. However, while functional for testing and early use cases, Launchtube does not have the maturity, scalability and auditing as OpenZeppelin’s Relayer, which is why the Stellar Development Foundation is discontinuing the Launchtube service and provides the managed Stellar Channels service as a replacement. +Launchtube, which served as an experimental service for fee sponsorship and contract invocations, has been instrumental in early-stage deployments and developer experimentation. However, while functional for testing and early use cases, Launchtube does not have the maturity, scalability and auditing as OpenZeppelin’s Relayer, which is why the Stellar Development Foundation is discontinuing the Launchtube service and points developers to OpenZeppelin's managed Stellar Channels service as the replacement. OpenZeppelin Relayer is an open source (AGPL-3.0) framework for submitting Stellar transactions, including Soroban contract invocations, with automatic parallel processing and fee management. If you [run your own instance](https://github.com/OpenZeppelin/openzeppelin-relayer), you hold the signing keys and you fund the accounts that pay the fees. From fa091b26a446145d8879eb5ad38ca81145221eb2 Mon Sep 17 00:00:00 2001 From: Elliot Date: Tue, 4 Aug 2026 11:30:00 -0500 Subject: [PATCH 4/5] Say Channels in the example comments and UI strings too Review feedback. The snippets still labelled the managed request as a Relayer request ("Build request for Relayer", "Submit to Channels Relayer", the button and result strings, and the error text), which kept the ambiguity alive inside the code. Only the package name still says relayer, since that is its real name. Co-Authored-By: Claude Opus 5 (1M context) --- docs/tools/openzeppelin-relayer.mdx | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/tools/openzeppelin-relayer.mdx b/docs/tools/openzeppelin-relayer.mdx index a1b47cf04f..39c891e390 100644 --- a/docs/tools/openzeppelin-relayer.mdx +++ b/docs/tools/openzeppelin-relayer.mdx @@ -98,12 +98,12 @@ const contractAuth = (op.auth ?? []).map((a) => a.toXDR("base64")); Now we have completed all necessary steps to submit a transaction to Channels. First the request is built, and then the request is submitted to Channels. ```typescript -// Build request for Relayer +// Build request for Channels const request: RPChannels.ChannelsFuncAuthRequest = { func: contractFunc, auth: contractAuth, }; -// Submit to Channels Relayer +// Submit to Channels const response: RPChannels.ChannelsTransactionResponse = await client.submitSorobanTransaction(request); ``` @@ -167,12 +167,12 @@ export const SendContractTransaction = async (sourceId: string, contractId: stri const op = assembled.operations[0]; const contractFunc = op.func.toXDR('base64'); const contractAuth = (op.auth ?? []).map((a) => a.toXDR('base64')); - // Build request for Relayer + // Build request for Channels const request: RPChannels.ChannelsFuncAuthRequest = { func: contractFunc, auth: contractAuth, }; - // Submit to Channels Relayer + // Submit to Channels const response: RPChannels.ChannelsTransactionResponse = await client.submitSorobanTransaction(request); // Poll for transaction result let txResponse = await rpc.pollTransaction(response.hash!); @@ -219,7 +219,7 @@ The page markup code checks if result contains a value. If not, the button for i > {result ? (

- Result from Relayer: {result} + Result from Channels: {result}

) : (

@@ -227,7 +227,7 @@ The page markup code checks if result contains a value. If not, the button for i className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" onClick="{callContract}" > - Call Contract via Relayer + Call Contract via Channels

)} @@ -262,7 +262,7 @@ export default function Home() {
{result ? (

- Result from Relayer: {result} + Result from Channels: {result}

) : (

@@ -270,7 +270,7 @@ export default function Home() { className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" onClick={callContract} > - Call Contract via Relayer + Call Contract via Channels

)} @@ -352,7 +352,7 @@ transaction.sign(sourceKeypair); Now we have completed all necessary steps to submit the transaction to Channels. The Channels client function `submitTransaction()` takes the transaction in XDR-format as an argument. ```js -// Submit to Channels Relayer +// Submit to Channels const response = await client.submitTransaction({ xdr: transaction.toXDR(), }); @@ -429,7 +429,7 @@ export const SendTransaction = async (destinationPublicKey: string, amount: stri return response.hash; } catch (error) { - console.error('Failed to submit Stellar transaction via OpenZeppelin Relayer:', error); + console.error('Failed to submit Stellar transaction via OpenZeppelin Channels:', error); throw error; } } From 1ef50c9b00a0754a739dad9dd5a733459048cc38 Mon Sep 17 00:00:00 2001 From: Elliot Date: Tue, 4 Aug 2026 11:38:37 -0500 Subject: [PATCH 5/5] Fix the comparative in the Launchtube sentence "does not have the maturity, scalability and auditing as" was ungrammatical. Adds "same", makes auditing a level rather than a thing Launchtube lacks outright, restores the serial comma, and matches the curly apostrophe used elsewhere on the page. Co-Authored-By: Claude Opus 5 (1M context) --- docs/tools/openzeppelin-relayer.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tools/openzeppelin-relayer.mdx b/docs/tools/openzeppelin-relayer.mdx index 39c891e390..e75edf018f 100644 --- a/docs/tools/openzeppelin-relayer.mdx +++ b/docs/tools/openzeppelin-relayer.mdx @@ -5,7 +5,7 @@ sidebar_label: OpenZeppelin Relayer sidebar_position: 43 --- -Launchtube, which served as an experimental service for fee sponsorship and contract invocations, has been instrumental in early-stage deployments and developer experimentation. However, while functional for testing and early use cases, Launchtube does not have the maturity, scalability and auditing as OpenZeppelin’s Relayer, which is why the Stellar Development Foundation is discontinuing the Launchtube service and points developers to OpenZeppelin's managed Stellar Channels service as the replacement. +Launchtube, which served as an experimental service for fee sponsorship and contract invocations, has been instrumental in early-stage deployments and developer experimentation. However, while functional for testing and early use cases, Launchtube does not have the same maturity, scalability, or level of auditing as OpenZeppelin’s Relayer, which is why the Stellar Development Foundation is discontinuing the Launchtube service and points developers to OpenZeppelin’s managed Stellar Channels service as the replacement. OpenZeppelin Relayer is an open source (AGPL-3.0) framework for submitting Stellar transactions, including Soroban contract invocations, with automatic parallel processing and fee management. If you [run your own instance](https://github.com/OpenZeppelin/openzeppelin-relayer), you hold the signing keys and you fund the accounts that pay the fees.