Build with more
transaction context.

Getting started

TXMORA is building transaction intelligence for applications that want to explain what a blockchain interaction may do. A future integration will start with a published base URL, a versioned schema, network-by-capability coverage and test credentials. None of those production prerequisites are available in this preview.

Before integrating, confirm the product capability you need, the exact network, input size limits, state freshness expectations and how unsupported transactions will be returned. A successful HTTP response should never be presented as proof that a transaction is safe.

Authentication

Authentication is planned for server-side API clients. A future launch should document key creation, scope, rotation and revocation before issuing credentials. Do not embed a private API key in browser JavaScript, a public Git repository or a mobile application package where it can be extracted.

End-user wallet connections, if supported by a future product, should be separate from API authentication and should request only explicitly described permissions. TXMORA does not require a wallet seed phrase to inspect public transaction data.

API overview

The planned surface groups requests by task: transaction scanning, simulation and wallet permission/activity analysis. Versioning, response schemas, request identifiers, pagination and timeout behavior will be defined before a production API is offered.

These route names are design examples; they do not resolve to a service today. A future contract will publish request and response schemas, supported chain identifiers and error behavior together.

Scan endpoint Planned

A proposed scan request would accept a chain identifier and transaction data or a transaction hash. The service would need to state whether it uses a supplied raw transaction, a public node or another data provider, and would return findings with source evidence and limitations. The following is a shape illustration only.

// Illustrative only — no live TXMORA host
const request = {
  chain: "eip155:1",
  transactionHash: "0x…",
}
// POST to a host provided at a future launch

Potential findings may include decoded instructions, observed asset movements, permission changes, source references and coverage limitations. A missing finding is not a safety verdict. Unsupported or unrecognized inputs should return an explicit status instead of an empty success result.

Simulation endpoint Planned

A future simulation request would specify chain context and transaction parameters. Its response should identify the state snapshot used, expected execution status, estimated balance changes and any unsupported calls or missing state. State can change between simulation and inclusion, so estimated effects must remain clearly identified as estimates.

EVM and Solana require different execution models. Capability status must be specified per network and transaction type; an EVM example does not imply Solana simulation availability.

Wallet endpoints Planned

Wallet-analysis routes are intended for read-only queries against public account activity and supported permissions. Future documentation should define address validation, pagination, chain coverage, indexer freshness and rate limits. Wallet monitoring should never require a private key or silently initiate an on-chain transaction.

• Approval discovery: supported token allowance patterns only.
• Activity history: indexed events with traceable transaction identifiers.
• Risk context: findings with source, freshness and confidence descriptions.

Address ownership cannot be inferred reliably from public transaction history alone. Any clustering or attribution requires separate, explicit methodology and uncertainty labels.

Supported networks

Ethereum, Base, Arbitrum, Polygon, BNB Chain and Solana are the initial intended network scope. Each must pass integration and capability testing before appearing as Live or Beta. At present, all network support is Planned and no analysis endpoint is connected.

Errors and limits

Production error codes and request limits are not yet published. A future API should distinguish malformed input, unsupported network or transaction, unavailable state, authorization failure, rate limit and temporary dependency outage. Retry behavior must follow the documented error class; clients should not retry every failure blindly.

Limits, quotas and service commitments will be stated only when a public service exists.

Security guidelines

Use server-side secret storage for API credentials, validate request parameters and minimize the data you send. Do not collect seed phrases or private keys. Render findings with their evidence, scope and limitations, and keep transaction signing inside a user-controlled wallet flow.

A TXMORA finding should be treated as decision support, not an authorization to bypass independent review. No analysis result can guarantee complete safety from scams, malicious code or changing chain state.

FAQ