FAQ

circle-info

The SDK only creates off-chain wallet ownership proofs for Travel Rule compliance. It cannot move funds.

Does the SDK only sign Travel Rule attestations, or can it also sign blockchain transactions that move funds?

The SDK is limited to signing Travel Rule wallet ownership attestations (off-chain proofs that a customer controls a wallet). It does not create, sign, or broadcast blockchain transactions.

The SDK signs a deterministic, plain-text attestation using personal_sign on Ethereum, or equivalent signing methods on other chains.

I certify that <chain> account <address> belonged to <customerDID> on <UTC timestamp>.

The SDK does not call transaction-signing methods such as eth_sendTransaction or eth_signTransaction, which wallets use to submit or authorize fund movement.

After signing, the SDK verifies the signature and returns a proof object that the host application can independently validate.

What key material does the SDK access, and are Travel Rule keys kept separate from transfer-capable keys?

The SDK does not access, store, or manage private keys.

The host application provides the wallet address, which is a public identifier. The user's wallet performs the signing operation through WalletConnect or a similar wallet integration, so key custody remains with the wallet provider and end user.

The SDK only helps the user select a wallet and request a signature. Because the SDK does not handle private keys, Notabene does not manage any SDK signing keys that could transfer funds.

Can we independently inspect the payload before it is signed, or is there any blind signing?

No blind signing is required. Blind signing means approving a signature without seeing the full message first.

The SDK signs a deterministic, plain-text attestation using personal_sign, and the wallet shows the exact message to the user before approval. Users can inspect the full payload directly in their wallet before signing.

The same attestation text is included in the proof object returned by the SDK, so customers can inspect, store, audit, and independently verify the signed payload after signing.

How are SDK releases protected against supply-chain compromise?

SDK releases use trusted publishing and include software supply-chain protections such as:

• Code signing: verifies that an artifact came from an authorized publisher.
• Build provenance: records where and how an artifact was built.
• Checksums and verification metadata: help customers detect tampering after publication.

These protections help customers verify that SDK artifacts originate from Notabene's authorized build pipeline.

For additional transparency, npm provenance information is available for the JavaScript SDK: https://www.npmjs.com/package/@notabene/javascript-sdk#provenance

Notabene's development and release processes are also covered by SOC 2 Type II controls (an independent audit of operational security controls), including secure software development lifecycle (SDLC), change management, access controls, and deployment controls. SOC 2 does not certify specific SDK functions, but it validates the controls governing SDK development, testing, and release.

Has the SDK undergone an independent security audit?

Notabene maintains a SOC 2 Type II program covering the platform and the controls used to develop and operate services, including Travel Rule compliance and wallet ownership proof.

If a customer requires information about SDK-specific or third-party security assessments beyond SOC 2, Notabene can provide additional details on request.