License Model

TradeScript Pro Charts is proprietary software licensed under your executed commercial agreement. The agreement defines your permitted use. The technical controls described here ensure that a customer SDK build runs only for its registered deployment and licensed capabilities.

Outcome

You know which release and authorization values belong to your deployment, where each value is used, and which changes require coordination with TradeScript.

Before you start

• An executed TradeScript commercial agreement
• A named deployment contact on your team

Done when

The package version, build fingerprint, approved origins, capability policy, and credential are recorded in trusted deployment configuration.

Typical time

10 minutes

The five parts of a licensed deployment

Part	What it controls	Where it is used
Commercial agreement	The legal right to install and use the software	Contract and account records
Customer SDK build	The code and embedded build identity supplied for your deployment	Your application bundle
Deployment record	Approved origins, SDK version, capability policy, ownership, and contract reference	TradeScript release and authorization systems
Backend credential	Permission to request a lease for that deployment	Your backend secret manager and lease endpoint
Deployment lease	Time-limited authorization for one customer build and its signed policy	Backend cache, then SDK creation in the browser

These parts are related but not interchangeable. Package access alone does not authorize a customer build, and a deployment lease does not grant rights beyond the commercial agreement or the signed capability policy.

What a deployment lease binds together

The authorization service signs a lease for:

• the fixed TradeScript issuer and @tradescript/pro audience;
• your authorization client and credential identity;
• one exact SDK version and customer build fingerprint;
• one or more exact approved browser origins;
• an issue time, activation time, and expiry; and
• the deployment policy and its entitlement-catalog version.

The customer SDK verifies those claims before licensed surfaces start. A valid signature is not enough: the current origin, SDK version, build fingerprint, time window, and policy catalog must also match.

Licensed capabilities

The signed policy may authorize or limit:

• SDK modules and chart features;
• built-in indicators and drawing tools;
• trading operations;
• worker capabilities; and
• numeric product limits.

The SDK fails closed when a capability is omitted or denied. Your application should still hide unavailable product actions where appropriate, but it must not treat frontend visibility as the authorization boundary.

Credential and lease handling

Value	Handling rule
Credential ID and secret	Permanent backend credential. Store only in a secret manager; never send it to a browser.
Customer build fingerprint	Release identifier. Read it from trusted deployment configuration, not browser input.
Deployment lease	Browser-deliverable bearer value. Cache it on the backend, avoid persistent browser storage, and never include the complete value in logs.

A deployment lease is valid for no more than seven days. The exchange response includes renewAfter and expiresAt; renew from the former and stop serving the lease at the latter. Long-running browser sessions can install a valid replacement without recreating the SDK.

Origins and environments

Origins are exact: scheme, hostname, and port must match. Production origins must use HTTPS. Loopback development origins such as http://localhost:5173 may use HTTP, but they must still be included in the deployment's approved origin set.

Register every environment that will run the customer build—development, preview, staging, and production—before testing it. Do not accept an origin from a browser request and forward it into lease exchange; origins come from the TradeScript deployment record.

Changes that require a matching release

Coordinate with your TradeScript deployment contact before changing:

• the customer package or SDK version;
• the customer build fingerprint;
• an approved browser origin;
• the licensed capability policy or limits; or
• the backend credential.

During an upgrade or blue-green release, keep the old and candidate build fingerprints as separate authorization cache entries. Each browser must receive the lease that matches the build it loaded.

Evidence shipped with the build

Each build writes a CycloneDX bill of materials to dist/sbom.cyclonedx.json. It records the package version, the build fingerprint, the production dependency graph, and a SHA-256 digest for every shipped file. Use it to confirm that the artifact you deployed is the artifact registered for your deployment. See Supply chain.

Onboarding checkpoint

Do not continue until your deployment contact has confirmed the exact package, version, build fingerprint, origins, capability policy, credential delivery method, and support channel. If the commercial agreement and the technical deployment record differ, resolve that mismatch before release.

Next steps

Implement Production authorization to exchange the backend credential, renew one lease per active build, and deliver only that lease to the browser.