Developer docs
From a website folder to a link anyone can open.
New applications · Publish with TapeKit
Files and update behavior
Select a built static website folder with index.html at its root and relative resource paths. Do not include server code, private keys or .env files. Each file is limited to 8,400,000 bytes and the site to 5,000 paths. Review translations and the application icon. Files are written in chunks of up to 24,000 bytes: assets first, index.html last, then the homepage fallback. Updates take effect file by file, without an atomic whole-site switch. Unselected old paths remain.
Key storage and automatic signing
The main wallet normally confirms two initial transactions: gas funding and file-edit authorization. This page then signs upload transactions using the temporary key. Authorization lasts 24 hours and is renewed when less than 2 hours remain. Funding follows the official estimate with the current X Layer gas price and a balance reserve; it is not the final cost. The key stays in this tab’s sessionStorage and survives refresh; restoring a closed tab may restore it too. Refund the balance after uploading; the key is deleted after refund confirmation. Revoking authorization is a separate main-wallet transaction. The operator can edit and delete this container’s website files, but this grant cannot transfer main-wallet funds or the NFT.
Costs, authorization and activation
Container opening, site activation and transaction gas are separate. Fees come from official contracts and are checked again before signing. Funding supplies the temporary wallet with upload gas; it is not a platform fee. Refund the unused balance afterwards. If gas runs out, upload stops; review the same folder to fund and resume. Funding, the operator grant, container opening, activation and revocation are separate transactions. A first upload normally needs two main-wallet confirmations for funding and authorization. Opening or activating a site requires additional confirmations. This interface activates for 30 days; renew manually after expiry. There is no automatic payment.
TapeKit access and traffic rewards
New applications use the official TapeOut container, SiteRegistry files and DomainBinding activation record. The processor must be registered by both the official and FABX factories. Website management follows its circuit NFT; editing is frozen while listed. After upload and activation, open the FABX HTTPS link shown on the page. The gateway checks container identity, activation and each file’s SHA-256. X Layer names use <circuit ID>.2.<official processor number>.tape. The official HTTPS form is https://<circuit ID>-2-<official processor number>.tapekit.org; availability is maintained by the official operator. Only visits through the FABX gateway that satisfy the existing anti-abuse and reward rules count toward platform traffic. Official and third-party entry points do not count. Uploading does not start a miner. Existing DeWEB and staking boost rules still apply.
Interruptions, refresh and refunds
Keep the upload tab running. After refresh, return to the same account and container and select the same folder. Already-uploaded bytes are verified before completed chunks are skipped. Resolve pending transactions in the transaction tray before retrying. Changing account or network pauses further automatic signing. After completion or interruption, refund the temporary wallet to the main wallet bound to that session. The key is deleted only after a confirmed refund; failed or pending refunds keep it available. Back up the key if the remaining balance cannot cover refund gas. Revoking the operator is separate and does not refund funds. Closing a tab may lose the key; restoring the tab may restore it. Closing is not cleanup. Refund before leaving, or make a secure private backup when necessary. There is no whole-site version rollback: restore a saved old build by uploading it again.
Existing IPFS applications
Existing IPFS applications retain their containers, CID version binding, URLs and signed upload flow. They are not migrated automatically and do not use this temporary-wallet mode. The original publishing and update handbook below applies to those applications.
Existing IPFS applications · Original publishing and updates
Publish your first app
Follow four steps to publish or update a website.
Before you start
- A wallet holding a circuit NFT
- A built static website folder
- OKB for on-chain transactions
- 01
Choose your circuit
Connect the owner wallet and select the circuit for your website.
No container yet? Check the fee, then sign to create it.
- 02
Upload your website folder
Select the built folder and sign a one-use upload authorization.
The platform uploads to IPFS, pins, then reads back and verifies every file.
- 03
Preview and publish
Preview the site when available, then check the circuit, CID and version.
Confirm the on-chain transaction in your wallet and wait for success.
- 04
Share your app
Copy the visit link or find the app in the DeWEB directory.
Visitors open the HTTPS link without a wallet or plugin.
Which folder should I upload?
Upload your build output, not your project source.
website/
├── index.html
├── deweb-icon.png
└── assets/
├── app.js
├── style.css
└── logo.svgindex.html
Required entry file at the root
Scripts, styles and images may use subfolders
Use relative asset paths, such as ./assets/app.js.
Never upload private keys, service secrets or .env files.
Give your app an icon
Choose a PNG on the deployment page. The platform previews and validates it before uploading it with your website to IPFS. You can also include deweb-icon.png at the website root; this publisher adds the declaration automatically.
PNG · 256 × 256 pixels · Up to 128 KiB · Static, non-interlaced, 8-bit RGB/RGBA. Published as deweb-icon.png.
Missing or failed icons use a default. Download the three examples below. Existing test apps use these samples until their developer publishes a custom icon.
Icons are pinned to the CID and version. Changing an icon requires the current circuit NFT holder to publish a new version and pay transaction gas. Published files cannot be replaced in place.
No site yet? Download the ZIP, extract it and select the website folder inside.
When do I sign or pay gas?
- Action
- Authorize upload
- Wallet confirmation
- Message signature: authorize these files
- Cost
- No gas
- Action
- Create a container
- Wallet confirmation
- On-chain transaction
- Cost
- Displayed contract fee + gas
- Action
- Publish or rebind a website
- Wallet confirmation
- On-chain transaction
- Cost
- Network gas
A successful upload is not a publication: complete the final on-chain confirmation.
Where do files, permissions and access live?
IPFS stores files
HTML, JS and CSS; a CID identifies this content.
The contract records the binding
Stores the CID, version and container link; the NFT controls publishing.
The gateway serves the site
Fetches files for the on-chain CID and returns them to the browser.
The browser runs the app
For Gomoku, the board, rules and AI all run locally.
How visits become mining weight
Boost connected · On-chain settlement determines activation
What counts as a visit
A rewarded visit requires today’s Cloudflare Turnstile verification followed by a successful application HTML navigation through our gateway, including cache hits. Each browser credential counts once per app per UTC+8 day. Failed or skipped checks, assets, refreshes, prefetches, embeds and detected automation do not count. Other gateways and direct IPFS access are excluded. Previous observation counts never become rewarded counts.
When it updates
Daily epochs begin at 02:00 UTC+8 using seven complete days ending yesterday. Boost starts only after the report and miner proof are confirmed on chain, with no backdating. It expires automatically at the next 02:00; settlement failure cannot extend it. Inactive miners are not started automatically. Rewards follow the current NFT holder. Emission is unchanged: boost changes pool allocation, not guaranteed income.
Boost formula · reward v1
T is the qualified total for seven complete days; S=T/7; bps=floor(2000*T/(T+7000)). Missing days are zero; 7000 visits yield 10.00%. Only base weight b*P is boosted, excluding design premium and additive to OKB boost. For each pool, with original weight B and requested additions R, the actual addition is min(R,floor(B/20)), shared proportionally. Exits, migrations and weight changes immediately rescale it to at most 5% of current original pool weight. Contract accrual uses integer precision; displayed weights round down.
T = sum(daily[].eligibleVisits) S = T / 7 bps = floor(2000 × T / (T + 7000)) percent = bps / 100
Public data and independent verification
/__fab/reward/summary exposes daily qualified counts; /__fab/traffic retains observations. Identity combines chain, site registry and container. Before submission, the service saves an immutable report with policy, domain, daily counts and Merkle proofs, then commits its root and content hash on chain. Compare report hashes with reports(epoch), verify verifiedBoost and inspect dewebWeights to check calculation and execution. This does not prove that every gateway observation represents a human.
Download verifiernode verify-deweb-traffic.mjs https://YOUR-APP/
Updates, permissions and troubleshooting
Open the topic you need.