ITZABUILD PORTAL · v0.8 Start building ↗
GUIDELINE 05

Build third-party off-chain connections carefully

Browsers can call CORS-enabled public services, but API secrets and privileged integrations belong behind a controlled server boundary.

← All guidelines

Boundary rules

  • Never embed third-party secrets in JavaScript; users can always inspect them.
  • CORS is permission from the remote service, not authentication and not a security boundary for your backend.
  • Send the minimum request to your backend. Apply authentication, rate limits, timeouts, size limits, and replay protection there.
  • Return a narrow, signed or otherwise verifiable result when a contract must rely on off-chain work.
  • Define what happens when the provider is slow, unavailable, or returns conflicting data.

Prefer native client proofs where they fit

The CDN PoW flow performs the expensive work locally without exposing a server secret: request a token, perform work in a worker, submit the solution, then claim it directly or pass its token ID to a contract call.

Proof-of-work lifecycle
const token = await itza.pow_request_token(
  wallet.keypair, applicationAddress, commitment, 10, CLUSTER_ID
);
const tokenId = token.signature;

const solution = await itza.pow_perform_work(token, (fraction, detail) => {
  showProgress(detail.phase, Math.round(fraction * 100));
});

await itza.pow_submit_completed(wallet.keypair, tokenId, solution, CLUSTER_ID);
await itza.pow_submit_claim(wallet.keypair, tokenId, CLUSTER_ID);
const finalToken = await itza.pow_get_token(tokenId, CLUSTER_ID);
Bottom line

Keep trust-sensitive work server-side or cryptographically verifiable, and design every external dependency as an unreliable dependency.