Overview

ObsidePad turns a public repository into the centre of a token community. A maintainer connects GitHub, proves they administer or maintain a repository, creates a project page, links a wallet with a signature, and launches a fixed-supply token on an available network. The server verifies every on-chain step by reading the chain itself before anything is shown as done.

A repository can have several independent deployments on different networks. They do not share supply, liquidity or bridging. Each one is its own token with its own address, receipt and authorities.

GitHub connection

• Sign-in uses the GitHub OAuth web flow with the minimal read:user scope. ObsidePad reads public repository data only; private repositories are not listed and their content is never fetched.
• The OAuth state is a signed, single-use cookie; the callback is rejected without it. Access tokens are encrypted (AES-256-GCM) at rest and never leave the server.
• Repositories are stored by their immutable GitHub id. Names and owners are display data that can change; the id cannot.
• “Repository access verified” means that at the shown time GitHub reported admin or maintain permission for the signed-in user on that repository id. It is re-checked before every sensitive project change. It is not an audit, an endorsement, or a guarantee of code ownership or safety.
• Repository activity (metadata, latest commits, releases, contributors) is synced by a durable job. Rate limits reschedule the job at the reset time and the page shows a stale state with the last sync time. Disconnecting GitHub revokes the token at GitHub and deletes the ciphertext.

Wallets

• Wallets connect through the injected provider (EIP-6963 discovery): MetaMask, Rabby, Coinbase Wallet and any other EVM wallet that supports Robinhood Chain. No seed phrase or private key is ever requested.
• Linking a wallet to an account requires signing a domain-bound, expiring (10 minutes), single-use EIP-4361 challenge. EOA signatures are verified offline; smart-account signatures (ERC-1271 / ERC-6492) through the chain client. Connecting alone proves nothing.
• The app detects the wallet’s own chain and asks it to switch (or add) the selected network. Rejections are shown as rejections, never retried silently.

Launching a token

1. Select a repository whose permission check passed.
2. Select a network that the registry reports as available.
3. Enter name, symbol, decimals, supply, description and image URL. Supply is handled as an integer in base units; floats never touch it.
4. Configure options: recipient of the whole supply (your linked wallet or another address).
5. Review the exact parameters, the signer, the recipient, the network and the estimated cost.
6. Sign in your wallet: one transaction through the ObsidePad factory on the selected network (Robinhood Chain by default).
7. The server tracks the transaction, reads the receipt and the token from its own RPC, and compares them with what you disclosed. A refresh mid-launch resumes from the server record and the chain.
8. The project page shows the verified token address, the transaction and the supply.

Contracts. ObsideToken is an OpenZeppelin ERC-20 with EIP-2612 permit and holder-level burn. The whole supply is minted once in the constructor to the disclosed recipient. There is no owner, no mint function, no pause, no blocklist, no transfer tax and no upgrade path. ObsideTokenFactory deploys tokens with CREATE2 (salt bound to the creator), records creatorOf(token) and emits TokenCreated(token, creator, recipient, name, symbol, decimals, supply, salt). The factory has no owner, no fee and no configuration. Build: solc 0.8.26+commit.8a97fa7a, EVM paris (valid on Arbitrum Orbit chains such as Robinhood Chain), optimizer 200 runs.

A token deployment does not imply tradability. Each deployment shows separate statuses for the token (deployed or not) and liquidity (“not configured” on every network, because ObsidePad implements no exchange or pool integration). There is no Buy button anywhere in the product.

Networks

ObsidePad is built for Robinhood Chain (chain id 4663) and its testnet (46630); the other EVM networks in the registry are expansion targets. The registry is server-controlled: for every network it records identifier, environment, RPC configuration, explorer, native currency, supported operations, the verified factory, and live health. Chain ids and endpoints were read from the official documentation listed on the supported networks page. A network is launchable only when (1) a factory deployment record exists and its runtime bytecode hash matches the current build, (2) the RPC answers with the right chain id, and (3) policy allows it (mainnets need MAINNET_LAUNCHES=1). The product never silently falls back from a mainnet to a testnet. Operators deploy the factory from their own wallet on the deploy page and record it with the verifier script.

Contributor rewards

• Disabled until the project has a confirmed token on a network that can verify transfers.
• The maintainer selects a contributor by linking the pull request or issue; the contribution and its author are read from GitHub, not from the form.
• A GitHub username does not establish a wallet address. The recipient is either the contributor’s own signature-linked wallet (looked up by GitHub user id) or an address the maintainer typed twice, labelled accordingly.
• The transfer is sent from the maintainer’s connected wallet, verified on-chain (Transfer event / token balance deltas) and recorded against the contribution with the transaction hash. One recipient per transfer; no automatic rewards for commit counts.

Treasury

A project may list public treasury addresses. Each is marked as maintainer-listed or signature-verified (control proven with a signed challenge). Balances of the native currency and the project’s own tokens are read live from the RPC; when a provider cannot answer, the page says so. ObsidePad never holds funds, never shows USD valuations and never fills in transaction history it cannot read.

$OBSIDE token

$OBSIDE is ObsidePad’s own community token on Robinhood Chain, separate from the tokens projects launch here. Its contract address is published on the token page only after the operator’s paste-ready command (pnpm token:ca 0x…) has verified the contract on-chain: checksum, contract code at the address, ERC-20 name/symbol/decimals/total supply, symbol equal to OBSIDE. Until then every surface reads “CA: Soon”. The page shows only what the contract reports and makes no claim about price, liquidity or utility.

Security model

• Every state-changing route requires a session, a same-origin check, schema validation and a rate limit. Project changes additionally require maintainer membership plus a fresh repository permission check.
• Client-submitted transaction hashes are hints. Deployments and rewards become confirmed only after the server reads the receipt / state from its own RPC and matches sender, contract, event and parameters.
• Challenges are single-use and expire; replay, cross-origin and cross-user attempts are refused.
• Markdown descriptions are rendered with an allow-list sanitiser; external URLs must be public https. Repository code is never executed.
• Webhook deliveries are signature-verified and idempotent by delivery id; job processing is idempotent and retried with backoff.
• Nothing in this product is audited. Testnet deployments are the supported path today; see the capability matrix.

Capability matrix

Generated from the registry at 01 Oct 2026, 11:54 UTC. “Available” is a live result, not a promise.

Not implemented in this version: liquidity creation and trading (no exchange integration exists), private repositories, batch payouts, multisig treasury verification. A network without a verified factory record (including Robinhood Chain until the operator deploys one) shows as unavailable rather than pretending.

Running your own

The repository contains the application, the contracts, deployment scripts, migrations and documentation (README.md, docs/SETUP.md, docs/DEPLOYMENT.md, docs/CAPABILITIES.md). The status page lists every integration with the exact variable it needs.