01 / Inspect
Target and interface
Validate a contract address, paste an ABI, and parse callable methods in the browser. Byteplane does not upload the ABI to an application backend.
Protocol paper / Version 1.0
Review the callbefore the wallet.
Byteplane is a local-first contract operations studio for inspecting interfaces, running user-triggered provider reads, preparing calldata, and exporting a portable unsigned transaction envelope.
01 / Purpose
Make contract intent inspectable.
Contract interfaces often compress an important decision into a wallet confirmation. Byteplane adds a review layer before that moment. It helps a user validate a target address, inspect an ABI, select a method, enter arguments, prepare calldata, and review an unsigned transaction object without silently submitting anything.
The current release is deliberately narrow. It is not a full indexing service, execution debugger, monitoring network, custody product, or guarantee that a transaction will succeed. A preflight result reflects the selected provider and state at the time of the request; state and fees can change before submission.
02 / Local-first workflow
From ABI to portable envelope.
02 / Read
Provider reads
Run an explicit read-only call through the user-selected browser provider. Results are summarized honestly, technical evidence is available through a user-initiated export, and no success state is invented.
03 / Compose
Calldata and estimate
Encode a selected write method locally, assemble to, value, and data, then request an optional gas estimate.
04 / Verify
Unsigned envelope
Normalize the transaction intent, compute its SHA-256 digest, and export a JSON envelope that can be imported and verified locally.
03 / Evidence model
Integrity, not execution assurance.
The unsigned envelope records the intended address, call data, value, network context, creation time, and digest. Deterministic serialization lets another browser verify whether the exported body has changed. It does not prove that a contract is safe, a method is appropriate, an estimate remains accurate, or the transaction was submitted.
A local watchlist can retain selected addresses and labels in localStorage. It is a browser convenience, not a live alerting service. Removing browser data or changing devices may remove the list.
04 / Web3 boundary
Every network action is separate.
Connect
Requests the active public account and network context only. It does not sign, send, pay, or activate points.
Read
Runs only after the user asks for a provider read or estimate. Returned data is displayed without recasting an error as success.
Send
Requires a distinct transaction preview, network match, and wallet confirmation. Byteplane never sends automatically.
Record
Any future public anchoring flow must show the exact digest and request its own explicit transaction.
05 / Ecosystem contribution
Open building blocks for safer calls.
Byteplane contributes a small, inspectable interface for transaction intent rather than a closed execution service. Builders can adopt the envelope format independently, generate compatible records in another interface, or verify an exported record without using the Byteplane brand.
- A versioned transaction-envelope schema with explicit required fields.
- A real example envelope that exercises the same local verifier as the product.
- An ABI method manifest for consistent read and write method presentation.
- Canonical serialization and digest rules designed for cross-tool reproduction.
- A clear separation between local preparation, provider reads, wallet consent, and public state.
06 / Participation
Optional actions, explicit consent.
Users may activate 100 local participation points through a separate control. Points are not a token, have no stated monetary value, and are not created by connecting a wallet.
An optional 0.37 BOT upgrade may increase the local display to 200 points only after a real, successful, matching payment. It requires a dedicated review and wallet confirmation. The payment control remains disabled until a verified recipient is publicly available.
07 / Risk and roadmap
Guardrails before expansion.
- Input risk: an incorrect address, ABI, method, argument, or value can produce a harmful transaction intent.
- State risk: contract state, balances, fees, and method behavior can change after preflight.
- Provider risk: incomplete, delayed, or malicious responses can produce inaccurate reads.
- Wallet risk: compromised devices, extensions, approvals, or copied addresses can cause loss.
- Contract risk: Byteplane cannot establish that an external contract is secure or behaves as described.
Near-term work is limited to improving envelope portability, verification fixtures, network compatibility checks, and clearer transaction review. Deployment of any anchoring contract requires separate technical review and public documentation.