Changelog

We have added support for creating and deploying ZK Proof based token contracts with Stylus. The templates provide you with Stylus contracts, ZK circuit files, and a ready-to-deploy Next.js app + API for proof generation and minting.

This guide walks you through building a privacy-preserving ERC721 token system using Zero-Knowledge proofs on Arbitrum Stylus. Users can mint tokens by proving they own a minimum amount of ETH without revealing their exact balance.

• ZK Circuit: Proves token ownership without revealing exact balances
• Stylus Contract: Rust-based ERC721 contract that verifies ZK proofs
• Frontend: Next.js app for generating proofs and minting tokens
• Oracle System: Secure balance verification mechanism

• Node.js (>= 20.18.0)
• pnpm package manager
• Rust with cargo
• circom for ZK circuits
• Stylus CLI for contract deployment

npx thirdweb create-stylus

Select "Stylus ZK ERC721" from the dropdown menu. This will:

• Clone the repository to your machine
• Set up the project structure
• Install basic dependencies

git clone https://github.com/thirdweb-example/stylus-zk-erc721.git
cd stylus-zk-erc721

Install dependencies for all components:

# Install root dependencies
pnpm install
 
# Install circuit dependencies
cd circuits
pnpm install
cd ..
 
# Install frontend dependencies
cd app
pnpm install
cd ..

Run the setup script to generate oracle keys and build the ZK circuit:

chmod +x setup.sh
./setup.sh

This script will:

• Generate a random oracle secret key
• Inject the secret into the ZK circuit
• Compile the circuit with circom
• Generate proving and verification keys
• Create the trusted setup for Groth16

⚠️ Important: The oracle secret is critical for security. Keep it private!

cd contracts
npx thirdweb@latest deploy-stylus -k <THIRDWEB_SECRET_KEY>

cd contracts
cargo stylus deploy --endpoint arbitrum-sepolia

Copy the deployed contract address - you'll need it for the frontend.

Update the contract address in your frontend:

cd app
# Edit pages/index.tsx or lib/config.ts
# Update ZK_MINT_CONTRACT_ADDRESS with your deployed address

Create environment file:

# app/.env.local
RPC_URL=https://sepolia-rollup.arbitrum.io/rpc
ORACLE_SECRET_KEY=<your_oracle_secret_from_setup>

cd app
pnpm dev
# Visit http://localhost:3000

1. Connect Wallet: Connect to Arbitrum Sepolia testnet
2. Generate Proof: Click "Generate ZK Proof" - this proves you have sufficient balance
3. Mint Tokens: Use the proof to mint ERC721 tokens

The core circuit (circuits/token_ownership.circom) has these components:

template TokenOwnership(oracle_secret) {
    // Private inputs (hidden from public)
    signal input actual_balance;        // Real balance from oracle
    signal input salt;                  // Randomness for uniqueness
    
    // Public inputs (visible on-chain)
    signal input min_required_balance;  // Minimum threshold
    signal input token_contract_hash;   // Which token to check
    signal input user_address_hash;     // User's address hash
    signal input timestamp;             // When oracle signed data
    signal input oracle_commitment;    // Oracle's commitment
    
    // Output
    signal output nullifier;            // Prevents replay attacks
}

Replace the balance check with custom logic:

// Original: Simple greater-than check
component gte = GreaterEqThan(64);
gte.in[0] <== actual_balance;
gte.in[1] <== min_required_balance;
gte.out === 1;
// Custom: Logarithmic scaling
component log_check = LogarithmicCheck();
log_check.balance <== actual_balance;
log_check.threshold <== min_required_balance;
log_check.out === 1;

Extend the circuit to verify multiple token balances:

template MultiTokenOwnership(oracle_secret, num_tokens) {
    signal input actual_balances[num_tokens];
    signal input min_required_balances[num_tokens];
    signal input token_addresses[num_tokens];
    
    // Verify each token separately
    component checks[num_tokens];
    for (var i = 0; i < num_tokens; i++) {
        checks[i] = GreaterEqThan(64);
        checks[i].in[0] <== actual_balances[i];
        checks[i].in[1] <== min_required_balances[i];
        checks[i].out === 1;
    }
}

Add expiration logic to proofs:

// Add time validation
component time_check = LessThan(64);
time_check.in[0] <== timestamp;
time_check.in[1] <== max_timestamp;  // New public input
time_check.out === 1;

After modifying the circuit:

cd circuits
pnpm run build
 
# Re-inject verification keys
cd ..
node scripts/inject-vk.js
 
# Recompile contract
cd contracts
cargo build

• thirdweb Arbitrum Documentation
• Arbitrum Stylus Documentation

Need help? Please reach out to our support team.

We’ve made several updates to the BuyWidget component to make it more flexible, interactive, and user-friendly - giving users more control while simplifying integration.

Clicking on the selected token opens a Modal that allows changing the selected chain and token. chain, and amount props are now optional

Both the fiat and token amount fields can be edited, making it easier to input custom fiat amounts beyond just selecting the suggested fiat amounts.

The wallet's current balance is also shown in the bottom-right corner which helps in choosing the buy amount

A button is added on the top-right corner that shows the connected wallet, Clicking on it opens the Wallet Details modal, which allows switching the active wallet or disconnecting the wallet

Try out the new and improved BuyWidget in playground

TLDR: The thirdweb API from fields when transacting are now optional - this is powered by the newly launched Project Wallets - go set one up!

When you’re orchestrating transactions from your backend, repeating the same sender address in every payload is the definition of busywork. Starting today, you can skip it. Authenticate with your project’s secret key, leave off the from field, and we’ll launch those transactions straight from your project wallet.

• Automatic sender fallback for server-side flows that use your project secret key.
• Works everywhere you submit encoded calls, trigger wallet actions, deploy or write contracts, mint tokens, process payments, or swap via the bridge API.
• Still honors explicit from values when you need to override the default.

Removing boilerplate means less room for typos, quicker prototyping, and cleaner shared helpers. Your integrations stay lean while every transaction still resolves to the right wallet.

curl https://api.thirdweb.com/v1/transactions \
  -H "Content-Type: application/json" \
  -H "x-secret-key: <your-secret-key>" \
  -d '{
    "chainId": 421614,
    "transactions": [
      {
        "data": "0x",
        "to": "vitalik.eth",
        "value": "0"
      }
    ]
  }'

No from required—just the secret key that unlocks your project wallet.

We’ve introduced Project Wallets as a first-class part of the dashboard so every project comes with a managed server wallet you can see, fund, and control right from the overview screen.

The Project Wallet section will stick around under Overview, giving teams a home base for balances, addresses, and actions.

Send funds or refresh balances right from the card, with labels and addresses trimmed for clarity.

Kick off transfers or open the funding modal without leaving the page.

When multiple server wallets exist, pick a new default directly from the card. The change propagates instantly across integrations.

You can autifill your project wallet in the Create a Payment and Earn Fees flows.

When using a managed Vault, you can use your secret key to interact with the Project Wallet - if you eject from the managed Vault, you may be prompted for an additional vault access token to interact with it. Via API, this looks like an additional x-vault-access-token header.

• Integration for gasless deployments — Token and Contract flows
• Integration into thirdweb API — will be used when a from address is not specified for your backend flows.
• Integration into any Transaction Button ("Execute" flow) you might encounter during your dashboard journey, from places like contract explorers for example.

Create a new project now!

Feel free to provide feedback @ https://thirdweb.com/support

You can now pay for any x402 compatible endpoint using the the new /v1/payments/x402/fetch API.

The new /v1/payments/x402/fetch in the thirdweb API proxies any url, and upon receiving HTTP 402 payment required response, automatically handles the payment with the authenticated wallet.

Query params

• url - target endpoint to fetch
• from - the wallet address to pay with
• method - optional HTTP method for the endpoint to fetch (defaults to POST)
• maxValue - optional max amount that can be paid
• asset - optional payment token, if not specified defaults to the target endpoint payment method
• chainId - optional payment chain, if not specified defaults to the target endpoint payment chain

Request body and headers will be forwarded to the target url.

You can use this from any language, any platform. Use it with your server wallets (using your project secret key) or with user in-app wallets (using the user JWT).

This makes is much easier to implement x402 payments for apps and agents.

Simply call this endpoint in your frontend or your agent tool to automatically pay for any x402 compatible endpoint.

• API reference
• Developer documentation

Happy building! 🛠️

We just shipped a pair of routes that make it painless to manage external wallets (via Sign-In-With-Ethereum aka SIWE) and other common authentication methods on user accounts. Both endpoints live under https://api.thirdweb.com and return fully normalized linked-account data so you don’t have to juggle different provider shapes.

Link an additional authentication method or wallet to your account.

Authentication Required: Client token + Wallet token

Request Body:

{
  "accountAuthTokenToConnect": "string"
}

Response:

{
  "linkedAccounts": [
    {
      "type": "siwe" | "guest" | ...,
      "id": "string",
      "details": { ... }
    }
  ]
}

Unlink an authentication provider from your account.

Authentication Required: Client token + Wallet token

Request Body:

{
  "type": "siwe" | "guest" | ...,
  "details": {
    "address": "0x...",        // optional
    "walletAddress": "0x...",  // optional
    "email": "...",            // optional
    "phone": "...",            // optional
    "id": "..."                // optional
  },
  "allowAccountDeletion": false  // optional
}

Note: At least one identifier in details is required.

Response:

{
  "linkedAccounts": [
    {
      "type": "siwe" | "guest" | ...,
      "id": "string",
      "details": { ... }
    }
  ]
}

We're continuously improving support for HTTP 402 payments in our SDK and facilitator API. Here's what shipped this week.

• Facilitator waitUntil option: Choose when a payment is considered fulfilled — simulated, submitted, or confirmed.
• Signature auto-detection: SDK now detects the correct signature type and EIP-712 domain/version based on asset address. No need to configure manually.
• Filters in /supported API: Filter supported tokens by chain or asset.
• New /prepare API: sign and encode payment payloads directly with the authenticated wallet.
• Revamped Playground: Select any token and try different config options in the UI. https://playground.thirdweb.com/payments/x402
• Documentation refresh: Updated guides for client, server, and facilitator APIs. https://portal.thirdweb.com/payments/x402

In case you missed it, here's what we shipped last week:

• Support for x402 payments in any ERC20 token
• Expanded USDC support to 26 new chains

Happy building! 🛠️

• This release introduces breaking changes — review the migration guide for a smooth upgrade.
• Updated Unity v6 documentation is live.
• Updated .NET v3 documentation are live (all of which can be used directly in this Unity SDK as needed).

• Reduced dependencies — fewer DLLs, all updated to the latest major versions.
• Unity package size cut by 40%.
• Significant performance gains across wallet APIs.
• Includes all performance upgrades from the .NET SDK v3 release, plus full access to the Thirdweb API wrapper via ThirdwebClient.Api. (See .NET release notes for details.)

• Removed: MetaMaskWallet and WalletConnectWallet.
• Added: Reown AppKit, the improved successor to WalletConnect.
  • If you rely on external wallets, migrate to AppKit — it’s more stable, faster, and actively maintained.
  • AppKit is optional and not bundled with the SDK. If you call ConnectWallet with WalletProvider.ReownWallet without setting it up, you’ll see descriptive errors guiding you through one-time setup.
  • Check the Migration Guide if you get stuck.

• PlaygroundManager has been simplified for readability and ease of use.
• The sample scene now includes the most common SDK features pre-wired for quick testing.

Full Changelog: v5.26.0 → v6.0.0

1. Unified client and APIs
2. Faster, lighter, and more efficient
3. Modern dependencies and standards
4. Easier wallet and transaction testing
5. Architecture ready for future features

Thirdweb .NET SDK v3 evolves from separate utilities into a cohesive, high-performance platform.

Unified API Client

// v2 – Separate clients
var nebula = await ThirdwebNebula.Create(client);
var pay = new ThirdwebPay();  
var bridge = await ThirdwebBridge.Create(client);
var insight = await ThirdwebInsight.Create(client);
// v3 – Unified client
var response = await client.Api.JustDoItAsync(...);

Highlights

• Low level generated client for thirdweb API full access, will be kept updated and the time-save will be used to make higher level APIs with nicer DX similar to the remaining ThirdwebWallet, ThirdwebContract and ThirdwebTransaction APIs.
• Consistent API design
• Easier discovery via IntelliSense
• Wraps the thirdweb API with all its features vs waiting for manual higher level integration
• Wrapper customized and adapted to work across any runtime and extended for game engine use.

Note that the core thirdweb functionality of Wallets, Contracts and Transactions is effectively free of breaking changes (new features are available). In the future, they may call into ThirdwebClient.Api while maintaining the nicer DX. There will eventually be an opinionated easier to use wrapper for each service.

Modernized Wallet Flow

// v2 – Private key wallet
var privateWallet = await PrivateKeyWallet.Generate(client);
// v3 – Guest/in-app wallets  
var wallet = await InAppWallet.Create(client, AuthProvider.Guest);
await wallet.LoginWithGuest();

Improvements

• Removed legacy signing and recovery methods from the IThirdwebWallet interface
• Removed obsolete LegacyEncryptionKey creaton param from In-App and Ecosystem Wallets.
• Major internal cleanup of legacy Shamir sharding client side logic and AWS logic.
• Better guest wallet flows
• Smarter gas handling and bundler integration

• Removed Portable.BouncyCastle and two other Nethereum dependencies.
• Updated remaining Nethereum dependencies to Nethereum 5.0.0
• Creating an In-App or Ecosystem wallet should feel a lot faster now.

Efficiency Gains

• 30% less code (6,997 → 4,886 lines)
• 41% fewer files (44 → 26)
• Faster builds and smaller runtime

Transactions

var hash = await transaction.Send();
var receipt = await transaction.SendAndWaitForTransactionReceipt();

Build System

• Modernized for faster development and testing
• If you want to contribute, we have a nice Makefile to help run things more easily

• Unified bundler (ThirdwebBundler)
• Improved gas estimation and sponsorship
• Better EIP-7702 support
• Better zkSync integration

• Unity Github
• Unity v6 Release
• Unity Documentation
• .NET Github
• .NET Release
• NuGet Package
• .NET Documentation
• .NET Generated Reference

• Native OAuth Integration: Added support for OAuth (social login) flows on macOS standalone builds using ASWebAuthenticationSession, integrated into the default CrossPlatformUnityBrowser.
• Universal Binary Support: Ships with an optimized native plugin (libMacBrowser.dylib) containing both ARM64 and x86_64 architecture support.

• Enhanced Security & UX: OAuth flows now use the system’s native web authentication session for better security, user experience, and compliance with App Store review guidelines.
• Improved Redirect Handling: Redirects now deeplink back into the app instead of following the Desktop Windows–style flow.
• Refined Platform Detection: macOS is now properly detected and handled in authentication workflows.
• Browser Selection Logic: Updated to ensure seamless use of the native macOS session.

• Native macOS plugin (libMacBrowser.dylib)
• MacBrowser class implementation
• Build instructions for compiling the plugin
• Updated browser selection logic for macOS builds

Note: This functionality only works in builds. In the Unity Editor, the original flow will still open a full browser.

Release: https://github.com/thirdweb-dev/unity/releases/tag/v5.26.0

We've redeployed bridge contracts with some updates that affect our Payments, Bridge, and Tokens products.

Users may be prompted to interact with a new contract.

• Old Contracts: 0xF8Ab2dBE6c43bf1a856471182290f91D621Ba76d, 0x7d34a477e2678c8e19d821eec103d4def4af6f4a
• New Contract: 0xdA864364f7D1ebCC7C89e9610eBdef45dDf5F81B
• ZK Contract: 0xC8EF2D40Ef314bb433f86ce2b67bA880BB48771b

We've updated our x402 facilitator and SDK to support any token that supports ERC-2612 permit functionality. Supporting this popular signature standard opens up x402 payments to virtually any ERC20 token.

• x402 facilitator and SDK now auto-detects ERC-2612 permit vs ERC-3009 transferWithAuthorization (USDC) and uses the right flow.
• settlePayment and verifyPayment now accept any arbitrary chain.

Client: pay-gated fetch using x402
auto detects ERC-2612 permit when supported, and signs the payment data accordingly.

import { wrapFetchWithPayment } from "thirdweb/x402";
import { createThirdwebClient } from "thirdweb";
import { createWallet } from "thirdweb/wallets";
 
const client = createThirdwebClient({ clientId: "your-client-id" });
const wallet = createWallet("io.metamask"); // or any other wallet
await wallet.connect({ client });
 
const fetchWithPay = wrapFetchWithPayment(fetch, client, wallet);
 
// Make a request that may require payment
const response = await fetchWithPay(
  "https://api.example.com/paid-endpoint",
);

Server: verify and settle via facilitator
When verifying/settling the payment define the price in the ERC20 token of your choice. Here's an example using $higher.

import { createThirdwebClient, toWei } from "thirdweb";
import { facilitator, settlePayment } from "thirdweb/x402";
import { base } from "thirdweb/chains";
 
const client = createThirdwebClient({
  secretKey: process.env.THIRDWEB_SECRET_KEY!,
});
 
const twFacilitator = facilitator({
  client,
  serverWalletAddress: "0xServerWalletAddress",
});
 
// e.g. Next.js Route Handler or middleware
export async function POST(req: Request) {
  const method = request.method.toUpperCase();
  const resourceUrl = request.nextUrl.toString();
  const paymentData = request.headers.get("X-PAYMENT");
 
  const result = await settlePayment({
    resourceUrl,
    method,
    paymentData,
    payTo: "0xTreasuryWalletAddress",
    network: base, // chain
    price: {
      amount: toWei("0.01"), // amount in wei
      asset: {
        address: "0x0578d8A44db98B23BF096A382e016e29a5Ce0ffe", // ERC-20 address
      },
    },
  });
 
  if (result.ok) {
    return new Response(
      { message: "Payment successful" },
      { status: 200 },
    );
  }
  return new Response(result.responseBody, {
    status: result.status,
    headers: result.responseHeaders,
  });
}

• Live playground
• Developer documentation

Happy building!

The BridgeWidget Script makes it easy to embed cross-chain swaps and fiat onramp UI into your app. Just add a script tag to your HTML and get a fully customizable widget — no build setup required.

• Cross-chain token swaps across 80+ blockchains
• Fiat onramp support to buy tokens with credit/debit cards
• Customizable UI — use prebuilt themes or override with your brand colors
• Prefill token selections for a smoother user experience
• Display fiat values in multiple currencies
• Event callbacks to track user actions (success, error, cancel, disconnect)

<!-- Add this script in <head> -->
<script src="https://unpkg.com/thirdweb/dist/scripts/bridge-widget.js"></script>
<!-- Add a container element where you want to render the UI -->
<div id="bridge-widget-container"></div>
<!-- Initialize the widget at the end of <body> -->
<script>
  const container = document.querySelector('#bridge-widget-container');
  BridgeWidget.render(container, { 
    clientId: "your-thirdweb-client-id",
    theme: "dark",
  });
</script>

View Documentation

We've extended the x402 protocol to support passing arbitrary chain ids, and expanded support to 13 new mainnets and 13 new testnets. You can now accept internet-native payments across a total of 35 chains.

In v5.109.0 of the thirdweb SDK, we've introduced new APIs to verify and settle payments and updated our client side API for multichain support.

Here's an example of using settlePayment within a Next.js API route:

// Usage in a Next.js API route
import { settlePayment, facilitator } from "thirdweb/x402";
import { createThirdwebClient } from "thirdweb";
 
const client = createThirdwebClient({
  secretKey: process.env.THIRDWEB_SECRET_KEY,
});
 
const thirdwebFacilitator = facilitator({
  client,
  serverWalletAddress: "0x1234567890123456789012345678901234567890",
});
 
export async function GET(request: Request) {
  // verify and settle the payment
  const result = await settlePayment({
    paymentData: request.headers.get("x-payment"),
    resourceUrl: "https://api.example.com/premium-content",
    method: "GET",
    payTo: "0x1234567890123456789012345678901234567890",
    network: "eip155:42161", // CAIP-2 format: "eip155:<chain_id>"
    price: "$0.10", // or specific token
    facilitator: thirdwebFacilitator,
  });
 
  if (result.status === 200) {
    // Payment verified and settled successfully
    return Response.json({ data: "premium content" });
  } else {
    // Payment required
    return Response.json(result.responseBody, {
      status: result.status,
      headers: result.responseHeaders,
    });
  }
}

You can pass any chain id as the network property using the CAIP-2 notation: eip155:<chain_id>. The thirdweb facilitator will handle settling payments on the given chain using the specified token, otherwise defaults to USDC.

Simply call settlePayment in your endpoint handler, middleware or agentic tool to process a payment everytime your API is called.

Here's the list of new chains supported (mainnet + testnet)

• Arbitrum One
• Celo
• Ethereum mainnet
• HyperEVM
• Linea
• Optimism
• Plume
• Polygon
• Sonic
• Unichain
• World Chain
• XDC

Learn more:

• Live demo on Arbitrum sepolia
• Developer documentation

Happy building! 🛠️

We’re launching SwapWidget - a pre-built, customizable UI that lets you easily add a cross-chain token swap UI to your app in just a few lines of code.

import { SwapWidget } from "thirdweb/react";
import { createThirdwebClient } from "thirdweb";
 
// 1. Create a thirdweb client
const client = createThirdwebClient({
  clientId: "YOUR_CLIENT_ID",
});
 
// 2. Render widget in your app
function Example() {
  return <SwapWidget client={client} />;
}

• View Live Playground
• View Documentation

We’ve just launched a new Tokens page. With this update, you can:

• Explore tokens by popularity, trends, and chains across different networks.
• See market data - token prices, 24-hour volume, and market caps
• Swap tokens across chains using thirdweb Bridge

Try it out: thirdweb.com/tokens

We're excited to announce the release of x402 payment support in the thirdweb SDK, enabling developers to monetize their backend and agent services with seamless, automatic crypto payments.

The x402 protocol is an emerging standard that extends existing 402 HTTP error with automatic crypto payments. When an API requires payment, it responds with a 402 Payment Required status code along with payment instructions. The client can then automatically fulfill the payment and retry the request—all without user intervention beyond the initial wallet approval.
Think of it as "pay-per-call" for APIs, where each request can be individually priced and paid for using cryptocurrency.

We've added two new functions to make x402 integration effortless:

Automatically handle paid API calls with a simple wrapper around the native fetch API:

import { wrapFetchWithPayment } from "thirdweb/x402";
import { createThirdwebClient } from "thirdweb";
import { createWallet } from "thirdweb/wallets";
 
const client = createThirdwebClient({ clientId: "your-client-id" });
const wallet = createWallet("io.metamask");
await wallet.connect({ client });
 
const fetchWithPay = wrapFetchWithPayment(fetch, client, wallet);
 
// This call will automatically handle payment if required
const response = await fetchWithPay(
  "https://api.example.com/premium-data",
);
const data = await response.json();

How it works:
1. Makes the initial API request
2. If a 402 response is received, parses payment requirements
3. Verifies the payment amount is within your specified limits
4. Signs the payment authorization with your wallet
5. Retries the request with the payment header
6. Returns the successful response

Integrate x402 payments into your endpoints or middleware stack with minimal configuration. Settles payments with your own server wallet, on 170+ chains and with 4000+ tokens

import { createThirdwebClient } from "thirdweb";
import { facilitator, settlePayment } from "thirdweb/x402";
import { arbitrumSepolia } from "thirdweb/chains";
 
const client = createThirdwebClient({ secretKey: "your-secret-key" });
const thirdwebX402Facilitator = facilitator({
  client,
  serverWalletAddress: "0xYourWalletAddress",
});
 
export async function GET(request: Request) {
  const paymentData = request.headers.get("x-payment");
 
  const result = await settlePayment({
    resourceUrl: "https://api.example.com/premium-content",
    method: "GET",
    paymentData,
    payTo: "0xYourWalletAddress",
    network: arbitrumSepolia,
    price: "$0.01", // or { amount, asset } for specific token
    facilitator: thirdwebX402Facilitator,
  });
 
  if (result.status === 200) {
    return Response.json({ data: "premium content" });
  } else {
    return Response.json(result.responseBody, {
      status: result.status,
      headers: result.responseHeaders,
    });
  }
}

Try the Live Demo
Experience x402 payments in action at our interactive playground.

Read the Documentation
Get detailed implementation guides in our x402 documentation.

Stay tuned for more x402 utilities and expanded functionality in the next few weeks!

Happy building! 🛠️

We've deployed new and improved bridge contracts that affect our Payments, Bridge, and Tokens products. The new contracts come with a variety of improvements including:

• Better execution prices and slippage resistance
• More informative events for transaction indexing
• Dynamic protocol fees for high-volume users

The new contracts are being iteratively deployed to all chains in the coming days. During the deployment period, users may be prompted to interact with a new contract.

Old Contract: 0xF8Ab2dBE6c43bf1a856471182290f91D621Ba76d

New Contract: 0x7d34a477e2678c8e19d821eec103d4def4af6f4a

ZK Contract: 0xC8EF2D40Ef314bb433f86ce2b67bA880BB48771b

The Nebula first party app - nebula.thirdweb.com - will be deprecated September 30th 2025 in favor of thirdweb AI.

If you have any funds in the nebula in-app wallet - please withdraw them by September 30th 2025.

To continue using the service, head over to the thirdweb dashboard and create a project. You will find the same functionality as before under the AI tab.

We will be shipping continuous updates and improvements to thirdweb AI in the next few weeks, stay tuned for announcements!

At thirdweb, our mission is to help builders succeed — from those starting their first project to teams scaling to millions of users. To keep improving, we’ve added a new feedback and rating feature in support in dashboard after ticket closure.

1. Go to your thirdweb dashboard, and at the team level, click Support from the left menu.
2. Open and create tickets or cases directly from there.
3. After an interaction with our AI agent or support team, and once your ticket is closed, you’ll see the option to:
   • ⭐ Leave a star rating
   • 💬 Add a quick comment about your experience

We take your feedback seriously. Every rating helps us identify what’s working well and where we can improve. This ensures we continue building the best tools and providing the best support for builders like you.

Our support team is here to help you integrate thirdweb and bring your ideas to life. Different plans come with different SLAs, which you can check out here: thirdweb.com/pricing.

We appreciate every single customer and your feedback is key to making thirdweb the best tool for builders. 🚀

• Endpoint: GET /v1/bridge/chains
• Description: Retrieves a list of blockchain networks supported for bridging.
• Details:
  • Returns chain ID, name, icon, and native currency details

Example Response:

{
  "result": [
    {
      "chainId": 1,
      "name": "Ethereum Mainnet",
      "icon": "https://...",
      "nativeCurrency": {
        "name": "Ether",
        "symbol": "ETH",
        "decimals": 18
      }
    }
  ]
}

• Endpoint: GET /v1/bridge/convert
• Description: Calculates the equivalent crypto token amount for a given fiat currency amount based on current market prices. This endpoint provides conversion rate estimates and does not execute any transactions.
• Parameters:
  • from (required) - Source fiat currency (broad list supported)
  • fromAmount (required) - Fiat amount (positive number)
  • chainId (required) - Target blockchain chain ID
  • to (required) - Ethereum address of the target token
• Response: Returns JSON with converted crypto amount.
• Performance:
  • Smart caching (30s fresh, 5m stale)
  • Rate-limited, requires client authentication

Example Usage:

GET /v1/bridge/convert?from=USD&fromAmount=100&chainId=42161&to=0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9

• Migration: Legacy endpoint pay.thirdweb.com/convert/fiatToCrypto replaced by /v1/bridge/convert.

Visit the full reference here.