Skip to main content

TLSNotary API Reference

TLSNotaryService Class

The TLSNotaryService class manages attestation tokens and proof storage. It provides methods for both direct execution and wallet-confirmation flows.

Methods

requestAttestation()

Requests an attestation token for a target URL. Burns 1 DEM and returns a proxy URL.

requestAttestationWithConfirmation()

Same as requestAttestation() but allows user confirmation before broadcasting. Recommended for wallet extension apps.

createTLSNotary()

Convenience method that handles the full setup: request token → get proxy → create TLSNotary instance → initialize WASM.

createTLSNotaryWithConfirmation()

Same as createTLSNotary() but with user confirmation. Recommended for wallet extension apps.

storeProof()

Stores an attestation proof on-chain or IPFS.

storeProofWithConfirmation()

Same as storeProof() but with user confirmation. Recommended for wallet extension apps.

calculateStorageFee()

Calculate the fee for storing a proof.

Response Types

AttestationTokenResponse

StoreProofResponse

TransactionDetails (for confirmation callbacks)

Native Transaction Types

TLSNotary uses two native transaction types:

tlsn_request

Requests a TLSNotary attestation. Creates an access token for the proxy.
Cost: 1 DEM (burned as fee)

tlsn_store

Stores the proof on-chain after notarization completes.
Cost: 1 DEM base + 1 DEM per KB (burned as storage fee)

Cost Structure

Example costs:
  • Small proof (1KB): 1 + 1 + 1 = 3 DEM + gas
  • Medium proof (5KB): 1 + 1 + 5 = 7 DEM + gas
  • Large proof (20KB): 1 + 1 + 20 = 22 DEM + gas

Error Codes

TLSNotary Class

The TLSNotary class performs the actual WASM-based attestation. Use it after getting a proxy URL from TLSNotaryService.

attest() Signature

The commit ranges and onStatus callback are passed as separate positional arguments, not as fields of the request object. The request (AttestRequest) fields are:

attest() Response

verify()

Verify an attestation proof:

Wallet Extension Integration

For production dApps, users connect via wallet extensions which handle key management. The SDK supports a 3-step flow for wallet extensions:

The 3-Step Wallet Flow

  1. Generate Transaction: Create the unsigned transaction
  2. Sign & Confirm: Send to wallet extension for user approval and signing
  3. Broadcast: Send the signed transaction to the network
The WithConfirmation methods implement this pattern:

Custom Headers

POST Requests

Commit Ranges (Selective Disclosure)

Control which parts of the request/response to include in the proof:
The attestQuick() method accepts an AttestOptions object where commit and onStatus are fields:
Larger commit ranges result in larger proofs, which increase storage costs. Only include the data you need to prove.