Files

defiQUG dbd517b279 Sync workspace: config, docs, scripts, CI, operator rules, and submodule pointers.

- Update dbis_core, cross-chain-pmm-lps, explorer-monorepo, metamask-integration, pr-workspace/chains
- Omit embedded publish git dirs and empty placeholders from index

Made-with: Cursor

2026-04-12 06:12:20 -07:00

6.6 KiB

Raw Blame History

Thirdweb Explorer Portal Deployment Model

Purpose

This document defines the correct integration model between:

the Chain 138 explorer access portal
Thirdweb Dashboard, CLI, and Engine/API
private or public source repositories
verification against the Chain 138 Blockscout explorer

It exists to prevent a common but inaccurate assumption: that Thirdweb's dashboard is a full private-repository deployment console by itself.

Bottom line

Thirdweb provides:

Dashboard and project/API-key management
CLI/browser deployment flow for contracts compiled from a local or CI checkout
Engine / HTTP API for backend-authenticated deploy operations
Optional publish flow for Thirdweb discovery/registry surfaces

Thirdweb does not replace:

your Git hosting
your CI build pipeline
your repo access and artifact generation
your explorer-side governance, approvals, and audit controls
your chain-explorer verification workflow

For a Chain 138 explorer portal, the clean split is:

explorer /access handles identity, RPC products, subscriptions, API keys, and eventually deployment permissions
your build worker or CI checks out repos and compiles artifacts
your backend holds the Thirdweb secret and performs deploy calls
your verification worker verifies against Blockscout using the same artifact metadata

What Thirdweb actually covers

Dashboard

Used for:

projects
analytics
API keys
contract inventory views

It is not the primary place where a user links a private GitHub repository and gets a full build-and-deploy DevOps experience.

CLI and browser flow

Typical path:

developer compiles locally or in CI using Foundry, Hardhat, or another supported tool
developer runs npx thirdweb deploy or npx thirdweb publish
browser flow opens
user connects wallet, chooses target chain, enters constructor args, and signs

This is usually the most direct Thirdweb methodology for developer-led deployments.

Engine / HTTP API

This is the backend-secured path.

Typical inputs:

chain ID
bytecode
ABI
constructor params
optional salt for deterministic deployment behavior where supported

Important:

this is a server-side authenticated integration
the secret key belongs on your backend or worker only
it must never be shipped to the browser

How this maps to the explorer portal

Explorer access portal responsibilities

The explorer portal should own:

explorer user identity
role and permission gating
RPC subscriptions and API key lifecycle
optional GitHub OAuth for repo linking
deployment approvals and audit logs
artifact immutability rules
allowlists for chains, factories, and deploy methods

Build system responsibilities

Your CI or worker should own:

repo checkout
dependency lockfile enforcement
compile commands such as forge build or hardhat compile
artifact generation
compiler version pinning
commit hash and artifact hash capture

Backend deploy responsibilities

Your backend should own:

storing THIRDWEB_SECRET_KEY
calling Engine / deploy API
choosing deploy mode
selecting chain ID
enforcing policy around from, sponsorship, and deterministic deployment

Verification responsibilities

Your chain explorer or verification worker should own:

Blockscout verification submission
constructor-arg alignment
compiler-settings alignment
reporting verification status back into the portal

Repository linking

If the portal offers “link repository”, that is your feature, not a native Thirdweb dashboard capability.

Recommended implementation:

user authenticates in the explorer portal
user optionally links GitHub using OAuth with minimal scopes
webhook or manual trigger starts a build job
build job checks out the repo and compiles artifacts
backend deploys using Thirdweb Engine/API
verification step runs against Blockscout

This keeps repo access and source provenance under your control instead of pretending the Thirdweb dashboard is the source-control authority.

CREATE vs CREATE2

CREATE

Normal deployment flow:

standard constructor deployment
address determined by sender and nonce

CREATE2 / deterministic deployment

Portal support should treat this as:

explicit operator or developer choice
optional salt
factory/path validation
artifact and bytecode consistency checks

The deploy worker must make sure:

the target chain supports the intended path
the selected factory/pattern is the one your stack expects
the same bytecode and constructor inputs are used for both deploy and verify

Supported developer stacks

The recommended portal model should treat these as compile sources, not deployment authorities:

Foundry / Cast
Hardhat
OpenZeppelin workflows
Remix-generated artifacts

Common output:

ABI
bytecode
constructor parameters
compiler metadata

These artifacts then flow into your backend deployment and verification pipeline.

Authentication and authorization

Use different credentials for different surfaces:

User-facing explorer auth

Use:

explorer login
optional wallet auth
optional GitHub OAuth

Purpose:

user identity
repo linking
audit ownership
deploy permission gating

Backend deploy auth