Terms and Enterprise Custody

These terms describe how Weenx holds and settles value on behalf of a Workspace, how the platform fee is applied, and how custody differs between the standard and Enterprise plans. They govern your use of the Integration API and the underlying settlement infrastructure, and they sit alongside your commercial agreement with Weenx.

01. Definitions

• Weenx — the payment infrastructure and the party providing the Service.
• Workspace — the merchant account boundary. Every API key resolves to one Workspace, and all balances, invoices, payouts, and settlement configuration are scoped to it.
• Workspace Owner (the Owner) — the party that controls a Workspace and its plan.
• Settlement wallet — the destination wallet, or set of wallets, to which a Workspace's settled funds are directed.
• Plan — the pricing tier attached to a Workspace: Starter, Growth, or Enterprise.

02. The Service and the custody model

Weenx provides payment infrastructure: invoicing and checkout, on-chain payment detection and confirmation, ledgering, payouts, reporting, and signed webhooks. Weenx does not provide custody-as-a-service as a standalone product, and nothing in these terms should be read as an offer of banking, deposit-taking, or investment services.

Custody differs by plan.

• Starter and Growth (pooled custody). Standard Workspaces settle through Weenx-operated custodial infrastructure. Received funds are held in Weenx-managed wallets, credited to the Workspace's balance on confirmation, and paid out under Weenx-operated controls. This is a custodial arrangement: Weenx operates the settlement wallets and their keys.
• Enterprise (dedicated, non-custodial settlement). Enterprise Workspaces may be provisioned on a dedicated, non-custodial, smart-contract settlement architecture, described in Section 03. This capability is gated by the Dedicated Wallets and Custom Settlement Schedules plan capabilities, which are available only on the Enterprise plan.

The plan capabilities that gate these surfaces are exposed to your integration on GET /v1/me and GET /v1/billing/plan, and enforced server-side: a Workspace whose plan does not include a capability cannot access the corresponding surface.

03. Enterprise Workspaces — Non-Custodial Smart-Contract Settlement

Enterprise Workspaces may be provisioned on a non-custodial, smart-contract settlement configuration. In this configuration a Workspace's settlement runs through dedicated on-chain smart contracts — a per-Workspace settlement controller and its associated receiving vaults — and the contract owner role and the signing authority over outbound movements are assigned to the Workspace Owner: the Owner's own keys, or an m-of-n multisig the Owner controls. Weenx acts as the orchestration and relayer layer between those contracts and the Workspace's developer surface, and executes on-chain actions only as directed and authorized by the Owner.

• Owner-assigned authority. The administrative functions of the settlement contracts — where settled funds are directed, changes to the destination wallets and per-asset thresholds, the token allowlist, and any on-chain recovery function — are gated by the contract owner role, which in this configuration is the Owner's. Weenx does not hold that role's keys and cannot exercise those functions on its own; it submits Owner-authorized transactions as a relayer.
• No key access. Weenx does not generate, store, or otherwise have access to the private keys or the signer set that hold the contract owner role or authorize outbound movements. Settled funds are routed on-chain directly to hot and cold destination wallets that the Owner designates and controls; Weenx does not hold those wallets' private keys and cannot spend, redirect, or freeze those balances.
• Owner-retained signing. Outbound movements that require a signature are authorized through a signing mechanism of the Owner's choice — an m-of-n multisig (for example a Gnosis Safe), an external HSM or KMS, an MPC signer, a client-managed / non-custodial signer, or an air-gapped signer. In these modes Weenx prepares and relays the transaction payload for the Owner's authorization but does not itself sign.
• Weenx as orchestration layer. The Service acts as the handler between the on-chain contracts (web3) and the Workspace's developer-facing layer (web2): it derives receiving addresses, deploys the Workspace's settlement contracts with the owner role set to the Owner's designated signer, prepares and relays Owner-authorized transactions, applies the configuration the Owner directs, observes and indexes on-chain events, and announces the resulting state to the dashboard, the double-entry ledger, the REST API, and signed webhooks.
• Web3 execution, web2 announcement. Transactions originate and reach finality on-chain, under the contracts' own authorization rules. The web2 layer is notified of that state — it is never a precondition for it. In any divergence between the two, the chain is the source of truth. See Section 04.
• Supported assets. This settlement model applies to supported fungible tokens (ERC-20 on supported EVM networks and TRC-20 on Tron); native-coin settlement is not routed through these contracts.
• Owner responsibility. Because the contract owner role, the signer set, and the settlement destination wallets are the Owner's, the Owner is solely responsible for safeguarding those keys and for reviewing the settlement contracts and their configuration before use. Weenx cannot recover funds that are lost or compromised through the Owner's keys or the Owner's own signing configuration.

Where a Workspace is not provisioned on this non-custodial configuration, settlement follows the custodial model described in Section 02. This section governs Enterprise Workspaces on the non-custodial configuration and operates alongside Section 02: Weenx provides payment infrastructure and does not provide custody-as-a-service.

04. The chain is the source of truth

For every Workspace, on-chain state is authoritative and the web2 record is a downstream projection of it.

• An incoming payment is credited only after it reaches the required number of confirmations for its network. Detection alone does not credit a balance.
• Ledger postings, dashboard state, the REST API, and webhooks are announcements of a state the chain already reached; they are never a precondition for it.
• On-chain reorganizations are followed: a payment invalidated by a reorg is unwound and re-credited only if it is re-mined canonically.

Build your integration to treat a confirmed on-chain state, reconciled through the read endpoints, as authoritative, and the webhook stream as fast notification of it.

05. Owner responsibilities, risk, and limitations

• Key custody. For a non-custodial Enterprise Workspace, the Owner is responsible for the security, backup, and recovery of the keys and signer set that control its settlement. Loss or compromise of those keys is the Owner's risk; Weenx cannot reverse an on-chain movement authorized by the Owner's keys or recover funds sent to a destination the Owner configured.
• Configuration. The Owner is responsible for the settlement destinations, thresholds, and token allowlist it configures, and for the destination addresses it whitelists for payouts.
• Operational controls. Payout, refund, and reversal execution is operator-gated by design; the Integration API can queue these requests but does not execute them on its own. The Owner is responsible for the operators it authorizes and the approval policy it sets.
• No financial advice. Nothing in the Service or these terms is investment, tax, or legal advice.
• Compliance. The Owner is responsible for its own regulatory obligations arising from its use of the Service, including any applicable licensing, sanctions screening, and tax reporting.
• Availability. The Service is provided on the terms of your commercial agreement with Weenx, which governs service levels, liability, and any warranties; these custody terms describe how custody and settlement operate and do not expand those warranties.

For the technical detail behind these terms, see Getting Started, Security and Authentication, and Payouts and Money Movement.