KAI User Agreement

1. Formation, scope and electronic acceptance

1.1 Parties and subject matter

This KAI User Agreement (the “Agreement”) is made between VN TECH LTD (the “Company”, “we”, “us” or “our”) and the individual using a KAI account or the organisation that the individual validly represents (“you”). It governs applying for an account, registration, identity verification, sign-in, authority, ongoing administration, restrictions, recovery and closure, together with related activity conducted through the account. KAI is the name used for the relevant Services. References to KAI mean the applicable service, system or act of the Company, as the context requires.

1.2 Electronic acceptance

You accept the version presented to you when, after being given a clear link and the relevant notice during registration, sign-in or authorisation, you select an acceptance box, select “Agree and continue”, complete authorisation or proceed in the manner described by that process. We may retain the agreement version, time and necessary authentication records associated with acceptance for the purpose of documenting formation. The evidential effect of a record remains subject to applicable law and the circumstances in which the record was produced; an electronic record is not made conclusive merely by being held in our system.

1.3 Access to the document

This Agreement is available on a public page before and after sign-in. You may save or print it using ordinary browser functions. Read the provisions concerning authority, instructions, permitted use, responsibility, account restrictions, closure and disputes before accepting. Where applicable law or an enterprise arrangement requires separate consent, a signature or a particular form of authority, that requirement must also be satisfied. Signing in does not replace a required enterprise contract or establish that a regulatory permission has been obtained.

If you do not accept a condition applicable to your intended use, do not complete that use and contact us through the channels below. An individual acting for an organisation should make these documents available to the organisation and ensure that internal approval covers the proposed activity. Incomplete internal approval must not be concealed by giving an inaccurate statement of authority to KAI.

2. Related documents, effect and interpretation

2.1 Function of each document

This Agreement operates together with the KAI Terms of Service, the KAI Privacy Policy, permission scopes presented during sign-in or authorisation, applicable capacity-agreement confirmations, fee disclosures, specific rules and written enterprise agreements. This document principally concerns account identity, authority and account activity. The Terms of Service principally concern markets, orders, funds, delivery, charges and API services. The Privacy Policy describes personal-information processing and associated rights; referring to it here does not amount to an irrevocable blanket consent to every optional processing activity.

2.2 Priority where provisions conflict

To the extent permitted by applicable law, a more specific enterprise agreement signed by appropriately authorised representatives takes priority concerning the matter it specifically addresses. A validly applicable confirmation or rule expressly supplied for a particular capacity agreement, order or service governs its particular subject. Provisions that do not conflict continue to operate together. The existence of a specific document does not, by itself, displace every provision in the other documents. No order of priority removes a right that the law does not permit the parties to waive.

2.3 Descriptions and individual communications

Product information and the Help Center explain features and procedures and should be read with these documents and the actual service status. Examples, screenshots, estimates and general explanations do not independently guarantee a particular fill, price, capacity allocation, response time or return. An explanation from support does not automatically amend an agreed commercial condition. Amendments to an enterprise contract, charge or allocation of liability require confirmation through the appropriate process by a person with authority.

Headings assist navigation and do not narrow the accompanying provisions. Expressions such as “including” must be interpreted in context rather than used to expand a permission beyond its stated purpose. Language versions are intended to communicate the same conditions. Please report apparent translation differences, broken links or incorrect cross-references before relying on them for an irreversible instruction. A language discrepancy does not remove protections required by applicable law.

3. Service provider, identification and contact channels

3.1 The contracting service provider

The Services are provided by VN TECH LTD, and KAI service operations are based in Hong Kong. Account rights and obligations between you and the Company are determined by this Agreement and the applicable related documents. The KAI name, a website address, an application name, a model name or a third-party identity mark on an authentication page identifies the relevant service or feature. It does not, without an applicable agreement, make another entity a party to this Agreement or establish that the entity guarantees the Company's obligations.

3.2 Correspondence information

Our correspondence address is 1312 17th Street, Suite 769, Denver, Colorado 80202, United States. General support and account enquiries may be sent to beidou@kai.com; our telephone contact is 400 108 2026. A correspondence address identifies where correspondence is directed. The service operating location, governing law and locations relevant to processing personal information are addressed separately in the applicable provisions and Privacy Policy and should not be inferred solely from a mailing address.

3.3 Verification of communications

Use a contact channel published in the Services or a verifiable in-service process for recovery, permission changes, organisation membership changes and closure. Independently verify an unusual link, request for credentials, change of payment recipient or urgent payment demand using an established official channel. A person's name, profile photograph, chat history or similar-looking domain does not by itself establish authority to change our contracts or receive funds on our behalf.

To help us locate a request, identify the account UID, registered email, category of request and relevant circumstances, while limiting attachments to necessary information. If you suspect impersonation, preserve the time, sender address and evidence that can safely be supplied. Do not disclose a password, one-time authentication code, recovery code, private key or full API key to test whether a purported representative is legitimate. We do not request these authentication secrets through ordinary email.

4. Eligibility, legal capacity and territorial conditions

4.1 Age and authorised use

You must be at least eighteen years old, have the legal capacity necessary to enter into and perform this Agreement, and be an enterprise or professional user authorised to use KAI. Accounts are not offered to minors. A guardian's willingness to assume responsibility does not automatically permit a minor to bypass eligibility requirements. Enterprise or professional status is determined by the applicable application, review and arrangements; it is not established merely by including a business name in a profile, using a particular email domain or accessing a public page.

4.2 Acting for an organisation

If you register or act for a company, partnership or other organisation, you confirm that you have effective authority for the relevant matters. That authority must cover account creation, acceptance of applicable documents, access to information and the intended business instructions. Do not act outside your assigned duties, under revoked authority, through another person's credentials or on the basis of an unverified agency relationship. Any applicable limits on amount, period, product or purpose must continue to be observed after sign-in.

4.3 Location and legal requirements

The Services may not be available in every country, region, industry or category of user. You are responsible for ensuring that your use, data submissions and transfers, payments, model content and business activity comply with applicable legal requirements and valid internal policies. Do not obtain access by misrepresenting location, concealing the actual user or evading an applicable restriction. A network connection tool does not change the legal obligations that apply to your activity.

We may request additional identity, organisation, authority or intended-use information where needed for legal, security or applicable admission requirements, and may restrict relevant functions pending verification. You should respond accurately to reasonable requests with the information necessary for their purpose; ordinary email should not contain unrelated authentication secrets. If your eligibility changes, promptly stop new activity outside your eligibility and contact us concerning existing records, outstanding matters and appropriate exit arrangements.

5. Account application, verification and service admission

5.1 Registration and verification

KAI accounts are created and authenticated through KAI Auth. Depending on the current process and available authentication methods, you may be required to verify your registered email, establish a password or passkey, complete two-factor verification, and provide organisation and authority information. The presence of an authentication option does not mean it is available for every device, territory or account. Follow the process actually offered to you and protect any recovery material supplied by that process.

5.2 Authentication is separate from admission

Production access is provided through invitation or approval. Account creation, email verification, issuance of an authentication session or successful sign-in establishes only the identity or sign-in step concerned. It does not automatically authorise real market access, account assets, orders, fulfilment, administrative functions or API use. Each capability remains subject to account approval, valid roles, the relevant service permission and server checks. An unapproved account must not obtain access by altering a client, repeatedly applying or borrowing another person's identity.

5.3 Application review

For legal, security and applicable admission requirements, we may request further verification, require renewed authentication or defer activation of a particular permission. Do not provide false, impersonated or unauthorised information, or use repeated accounts to conceal an earlier restriction. Application material should identify the actual user and responsible personnel. Nothing in this Agreement requires unrelated personal information to be sent through an unofficial channel.

Submission of an application, issue of an invitation, delivery of an email and activation of access are different events. An invitation or acknowledgement from support is not approval. The verified service status determines whether a capability is available. If a page continues to show pending approval, insufficient permission or authentication failure, follow the Help Center process and provide the error time and necessary identifiers. Waiting for admission or encountering authentication failure does not authorise a transition to demo mode, and the availability of controls in a demo account is not evidence of real-account approval.

6. Accuracy, maintenance and identification of account information

6.1 Maintaining accurate information

Keep the name or display name, registered email, organisation, assigned role, contact information and other account-administration information you provide accurate, complete and current. A display name is an interface identifier and is not necessarily a verified legal name. Do not use a name, image or description that misleadingly suggests that you represent the Company, a regulator or an unrelated organisation.

6.2 Changes affecting authority

A change of registered email, departure from an organisation, change of organisational control, expiry of authority or replacement of a representative may affect notices, recovery and permissions. Notify the organisation administrator or the Company through the appropriate process, and stop new activity based on authority that is no longer valid. Editing a profile does not transfer organisational assets, orders or contractual rights. Such matters require separate handling according to actual ownership, valid authority and the applicable service procedure.

6.3 Identifiers and verification

A UID is a system identifier that connects an account with its records. It is not a password or a substitute for authority. Knowing another person's UID, email or order number does not authorise access to their information, changes to their permissions or instructions on their behalf. Support may request identifiers to locate a problem while still requiring verification for a sensitive request. Avoid unnecessarily publishing links between account identifiers and financial records.

When reporting incorrect information, identify the field, its current value and the requested correction, with a reasonable basis needed for verification. A profile correction must not be used to erase a historical instruction, conceal the responsible person or change an already completed business event. Errors in historical records should be addressed through the relevant enquiry or correction procedure while preserving necessary audit links. Statutory correction and other personal-information rights are handled under the Privacy Policy.

7. Credentials, device protection and account recovery

7.1 Protecting authentication material

Use a unique password of appropriate strength, protect your registered email, trusted devices and recovery methods, and enter credentials only in a trusted application or verified authentication page. Do not sell, rent, lend or share an individual account. Sharing a password, session or remote-control connection must not allow an unauthorised person to operate under your identity. Where several people work for an organisation, use appropriate member identities and permissions so that responsibility remains identifiable.

7.2 Devices and working conditions

Lock the screen or sign out when leaving a device, and avoid retaining sessions on public or shared equipment. Apply device updates, access controls and malware protection appropriate to the activity. Consider whether browser extensions, clipboard utilities, recording software or remote-support personnel can obtain secrets without authority. Before a device is handed over, repaired, sold or recycled, appropriately address credentials and local information retained on it.

7.3 Loss, exposure and recovery

If a device is lost, a sign-in is unfamiliar, credentials may have been exposed, an instruction is unauthorised or an API key has leaked, promptly use a trusted device to stop affected activity, change relevant credentials, use available revocation controls and contact us. Recovery may require renewed verification of email, identity and organisational authority. Possessing an old screenshot or knowing a balance is not automatically sufficient evidence for account recovery.

Prompt reporting can limit subsequent risk but does not guarantee that an executed instruction can be reversed or predetermine responsibility for disputed activity. Preserve the event time, affected functions and necessary records. Avoid destroying relevant evidence or continuing to use a potentially compromised device. If a recovery step is unavailable, explain the problem through official support; do not provide authentication codes or make a payment to an unofficial person claiming to accelerate recovery.

8. Sign-in status, session validity and revocation

8.1 Continuing validity

A valid sign-in session is one requirement for protected functions, but it is not permanent authority. Expiry, sign-out, revocation, credential or permission changes, risk controls, device conditions, maintenance and other verification-related circumstances may invalidate a session or require authentication again. A cached photograph, account name or page does not establish that access remains valid. Each protected action must also satisfy the relevant server-side permission and security checks.

8.2 Handling different failure states

Use the official authentication process when identity credentials expire. If permission is insufficient, verify admission or role assignments rather than repeatedly refreshing credentials to bypass authorisation. A network failure or service error is different from invalid identity and must be interpreted with the available status information. Where account information cannot refresh, retained information may be used only as a clearly identified read-only reference and must not support new orders, funds changes or other write instructions.

8.3 Scope of sign-out and revocation

Signing out on a device, clearing local information, revoking a business session, closing a third-party identity account and closing a KAI account are separate actions. Their effect depends on the steps actually completed and acknowledged. Clearing credentials offline does not establish server-confirmed revocation. Signing out on one device must not be assumed to revoke every other device session or API credential. Following suspected exposure, identify the sessions and credentials that still require revocation.

Apple, Google, passkeys and other authentication methods, if offered, depend on the relevant platform's availability and terms. Successful third-party authentication does not confer independent KAI production permission. After signing in again or switching identity, check the UID, registered email, organisation, live or demo environment and information timestamp. If they do not match the intended context, stop and verify the position before acting, rather than carrying the previous account's assumptions into another account.

9. Organisational accounts, permission governance and personnel changes

9.1 Administrative authority

Within available functions and valid authority, an organisation owner or administrator may invite members, assign roles, approve or disable access, and inspect management and audit records necessary for those duties. Membership of an organisation does not give every member access to all organisational information or authority for every instruction. Administrative, funds, order and read-only permissions must be assessed according to their actual configuration and effective authorisation.

9.2 Internal controls

Use only the permissions assigned to you and comply with valid organisational requirements concerning approvals, amounts, purposes and separation of duties. Do not impersonate another approver, exploit a configuration error to elevate a role, combine multiple accounts to evade limits, or ask support to perform an action outside your authority based solely on an oral statement. Organisations should maintain current membership records and arrange appropriate handover when authority changes, responsibilities move or personnel leave.

9.3 Departures and continuity

When a person leaves, necessary business records should be handed over under lawful authority, unnecessary access and related credentials revoked, and continuing automated tasks reviewed. Disabling a member does not automatically cancel an organisation's validly submitted orders, remove charges already incurred or transfer the person's data rights. Handover should not require the departing person to disclose individual authentication secrets as a routine means of preserving continuity.

If individual and organisational instructions conflict, or several people make inconsistent claims to administrative control, we may consider account affiliation, the latest verifiable authority and signed enterprise terms, and restrict high-risk changes pending verification. An employment, agency or ownership dispute does not require us to transfer assets or broaden access without checking authority. A challenge should identify the disputed scope and the evidence of authorisation. Processing personal information in that context remains subject to the Privacy Policy and applicable law.

10. Electronic communications, service notices and delivery

10.1 Channels and subject matter

You agree to receive electronic communications concerning accounts, authentication, security, orders, fulfilment, service changes and legal documents through the application, web workspace, registered email, system notifications or a public page. Unless mandatory law requires otherwise, a notice is treated as delivered under this Agreement when sent to a valid channel you provided or made available in the account. Where a particular matter legally requires a different form of notice, that requirement continues to apply.

10.2 Contact information and receipt

Keep your registered email available, update contact details and reasonably review necessary account communications. Email filtering, an offline device, insufficient storage, disabled push permissions and organisational mail restrictions may affect when you actually see a message. System notifications are off by default. You control device push permissions, but disabling push notifications does not remove the need to review in-service announcements, order status, account records and security information.

10.3 Essential and optional messages

Necessary messages about verification, security, account status, charges, fulfilment and legal updates serve a different purpose from optional marketing. If marketing communications are offered, we will distinguish them and provide choices or unsubscribe methods as applicable. Ending marketing messages does not close the account and does not automatically block essential service communications. This Agreement does not treat acceptance of all marketing as a condition for understanding necessary notices.

A notification banner, email subject or summary may not show the complete business state and may become outdated following a later fill or processing event. For order results, balances or sensitive actions, return to a trusted service page and inspect the full records. Do not issue a new instruction solely on the basis of a fragment of a notification. If a message appears altered or contains an unfamiliar link, access the Services through an established entry point and verify it independently instead of entering credentials into the suspicious page.

11. Biometrics, local authorisation and sensitive actions

11.1 Choice and verification scope

Biometric authentication is off by default. Where supported by your device and the relevant feature, you may choose to enable it and follow the presented verification process when enabling, disabling or confirming a protected action. The device operating system performs biometric verification. KAI receives a result such as success, failure, cancellation or unavailability, rather than your face or fingerprint template. The Privacy Policy provides the relevant information-processing explanation.

11.2 Device checks and service permissions

A device check establishes that a local action met the authentication condition supported by that device. It does not replace KAI Auth identity, a valid business session, organisational roles or server-side risk checks. Passing a face, fingerprint or device fallback check does not mean that an order was accepted, funds changed or a missing permission was granted. Device verification and subsequent business processing must each be assessed using their own acknowledged result.

11.3 Shared devices and configuration

Understand who can use biometrics and alternative unlocking methods enrolled on your device, and manage those settings according to the account's actual risk. A shared device containing another person's enrolled verification information should not be treated as a tool that only you can authorise. Changing devices, resetting biometric enrolment, operating-system restrictions or other security changes may make the feature unavailable. Use the valid, supported process shown by the current interface.

Cancelled or failed verification does not establish completed authorisation and must not be bypassed by disabling required controls or using someone else's verification. If local verification succeeds but the business result is unknown, follow the original-request enquiry procedure rather than submitting again on the strength of the local result. You may change optional biometric settings, but doing so does not remove necessary authentication and permission checks for protected Services.

12. Live environments, demo mode and unavailable states

12.1 Nature and selection of environments

The live environment supports actual activity by an approved account with valid permissions and authoritative service connections. Demo mode uses local information isolated from real accounts solely to explain the interface and procedures. It does not create real orders, fills, positions, money balances, API credentials or fulfilment rights. Entry into demo mode requires your explicit selection of a demo entry point or mode. Failed registration, failed sign-in or service unavailability must not be interpreted as your selection of demo mode.

12.2 Blocking unsafe live actions

If real-account authentication fails, permission is insufficient, required service configuration is missing, the service is disconnected or a safe and complete account state cannot be obtained, related orders, funds changes and other write actions must be restricted or blocked. The condition must be represented by its actual error, recovery or read-only state. Simulated balances, positions or fills must not populate real-account results, and automatic fallback to demo must not make the interface appear to have restored live business operation.

12.3 Interpreting displayed information

Before acting, check the environment indicator, UID, organisation and information timestamp. A blank field, “—”, synchronisation status, last-known record and temporary unavailability have different meanings; none automatically means that the real value is zero. Visible market information does not establish that account assets or permissions have synchronised. Do not use demo values, old snapshots or example screenshots to decide a payment, purchase, sale or delivery.

Demo outcomes do not establish live prices, fill probability, latency, capacity or availability. They must not be represented as settlement evidence, fulfilment records or actual business results. If a real-account page shows demo identification or another account's information, stop write actions, record the time and necessary page details, and contact support. Do not test whether the account is live by repeatedly submitting orders while the discrepancy remains unresolved.

13. Electronic instructions, confirmation and result verification

13.1 Issuing and checking instructions

Orders, cancellations, sales, transfers, API-credential management, settings changes and other actions that you confirm in a valid session with appropriate authority may be processed as your electronic instructions under the applicable rules. A valid instruction issued for an organisation may also bind that organisation. Before submission, verify the account, subject, direction, price, quantity or lots, delivery period, validity, charges, information time and consequences. Automated systems should implement equivalent checks.

13.2 Submission, acceptance and completion

A clicked control, successful local authentication, a transmitted request, server acceptance and final business completion are distinct states. A page remaining unchanged, closing, refreshing or losing connectivity does not establish that the server never received the request. A cancellation or remedial instruction also requires a processing result; requesting cancellation does not itself prove that the original order has ceased to be effective. The Terms of Service and authoritative business records determine the applicable effect and processing sequence.

13.3 Pending and unknown outcomes

If the result is pending, unknown or lacks a receipt, preserve and use the original request ID to query the server receipt and inspect order, fill and funds records. Do not create a fresh request identifier and submit a seemingly identical business instruction. Refreshing the page, repeatedly pressing a control or switching devices is not, by itself, a safe retry method. When seeking assistance, provide the original identifier, time, environment and known status.

Promptly report suspected duplication, an incorrect subject or unauthorised activity and retain relevant evidence. Error correction, reversal and dispute handling follow the applicable Terms and verification procedure; they do not permit arbitrary deletion of original records or guarantee that a completed transaction will be unwound. The link between credentials and activity is evidence for assessment, without excluding lawful investigation of impersonation, system failure and each party's actual fault.

14. Account snapshots, business records and discrepancies

14.1 Authoritative records and their presentation

Account overviews, balances, positions, orders, fills, delivery and bills should be assessed using complete server snapshots and the relevant authoritative records. The interface presents those records and allows actions; its formatting, pagination, aggregation, conversion and refresh state do not alter the underlying business events. Reference exchange rates, valuations and combined currency totals do not replace original-currency ledgers or applicable settlement records. Display rounding does not independently change an amount owed.

14.2 Refresh and read-only states

Different sources may update at different times. A functioning market feed does not guarantee current personal-account information, and refreshing one tab does not guarantee a consistent snapshot of all orders, funds and fulfilment records. Where the complete state cannot refresh safely, we may retain the last available information, identify its timestamp and stale status, and stop related write actions. Observe those controls rather than bypassing them with an older client or automation.

14.3 Reporting differences

For a discrepancy, identify the account, relevant order or request, time, currency or product, displayed position and correction you believe is needed. Retain necessary receipts and screenshots, identifying their environment and time. Avoid combining different accounts, dates or demo results into a purported single business event. Support may need related preceding and subsequent records rather than relying on an isolated balance screenshot.

You may inspect or export records within available functions and applicable permissions, and should preserve what is needed for organisational audit, procurement and accounting. Exported files may contain account and business information; check authority and necessity before sharing them. Correction should preserve the relationship between actual events. This Agreement does not make an interface record incontestable evidence or remove your right to challenge an error and seek correction under applicable law.

15. Relationship to markets, funds and fulfilment services

15.1 Applicable business rules

When using the account for KAI model-capacity markets or fulfilment, you must also comply with the Terms of Service, specific capacity-agreement specifications and applicable confirmations. These address lots, Weighted TPM, delivery periods, gate close, order validity, batch price protection, prepayment, settlement, capacity expiry and model-use restrictions. Account-administration provisions do not replace those business conditions, and account access does not promise a particular price, fill or capacity outcome.

15.2 Permission is distinct from outcome

Approval, a balance, an assigned role or visibility of a product does not guarantee that every order can be submitted or filled. It does not establish capacity at every moment, completion of a withdrawal or suitability of model output for a particular purpose. Funds, positions, available capacity and API permissions must each be checked under their applicable rules. Assess the conditions relevant to your business and verify the specific limits that apply when you act.

15.3 Funds procedures and prohibited purposes

Deposits and withdrawals currently require assistance from the service team and must follow a verified official process and applicable information requirements. Do not use an account for unauthorised payment collection, funds transmission, financing, investment or resale, or as a conduit for unidentified third parties. An account name, note or internal classification does not change the actual ownership or purpose of funds.

Closure, role removal, device sign-out and API-key revocation do not automatically discharge charges already incurred, validly submitted instructions, unsettled matters or continuing fulfilment obligations. Before ending use, review outstanding orders, related balances and delivery arrangements and address them under the Terms. For service explanations, procedures and common questions, consult the Product Introduction and Help Center alongside the applicable agreements and actual records. An operational explanation should not be treated as a separate assurance of a commercial result.

16. API credentials, automated access and operational responsibility

16.1 Access and credential lifecycle

API functions apply only where the account has the relevant permission and the service supports them. A full key is displayed once when created and should be securely stored at that time. A retained name, prefix, status or other metadata does not mean the full key can be recovered. Creation, inspection of metadata, revocation and creation of a replacement are separate actions whose target account, purpose and outcome should each be checked.

16.2 Least privilege and storage

Apply least privilege, controlled storage, usage monitoring, rotation and revocation, and limit the people and processes able to read a key. Do not place full keys in source code, public repositories, chats, screenshots, public pages or ordinary support email. If exposure is suspected, promptly revoke the affected key through an available official process and review related usage. Deleting a local copy does not establish that server-side revocation occurred.

16.3 Automated activity

API instructions issued through account credentials are subject to corresponding permission, charging and responsibility rules for interface instructions. Ensure that automation observes limits, metering, gate close, price protection and business rules, recognises authentication failure, insufficient authority and unknown results, and applies suitable concurrency limits, backoff and original-request enquiries. Do not use multiple keys, multiple accounts or uncontrolled retries to evade restrictions or overload the Services.

Maintenance of automation by you or your supplier does not remove the need for valid authority, correct inputs and protection of secrets. Responsibility for activity caused by inadequate credential protection is assessed under the actual facts and applicable terms. A general attribution of activity does not exclude a different rule required by law or the Company's failure to take reasonable measures after timely notification. When an account is disabled or personnel change, separately review surviving keys and scheduled tasks rather than assuming that all automation has stopped.

17. Acceptable use, prohibited conduct and incident reporting

17.1 Lawful and honest use

Do not use, or allow another person to use, an account for unlawful, fraudulent or infringing activity, evasion of applicable sanctions or required permissions, harm to others' rights or harm to the Services. Do not impersonate users, organisations or service personnel; falsify authority, orders, receipts or business records; exploit errors for improper benefit; manipulate markets; create fictitious trades; or otherwise mislead the Services or other participants.

17.2 Systems and information

Without authorisation, do not access another user's information, bypass identity or access controls, elevate permissions, extract protected data, or probe or interfere with system security. Do not distribute malware, conduct denial-of-service activity, send abusive bulk messages, steal credentials, or impair availability through abnormal concurrency and repeated requests. Multiple identities, keys or network sources must not evade valid restrictions. Security testing expressly authorised and conducted within its agreed scope is distinguished from unauthorised attacks.

17.3 Content and upstream requirements

Model and content functions must comply with applicable law and relevant upstream model policies. Do not submit or distribute content involving child sexual exploitation, fraud, unlawful invasion of privacy, unlawful threats or other serious unlawful harm. A service interface must not be used to perform an act that you have no authority to perform directly. The technical ability to submit an input does not mean that its purpose has been reviewed or approved by the Company.

17.4 Reports and investigation

If you find an anomalous price, incorrect permission, access to another user's data, a security flaw or suspected abuse, stop further exploitation and report necessary, appropriately redacted information through an official channel. Do not continue accessing others' information or expand the impact merely to demonstrate a problem. We may preserve relevant logs, restrict affected capabilities and request reasonable cooperation for investigation, taking account of the facts, risk and applicable rules. You may explain an apparent error and challenge a restriction under the review process described below.

18. User content, processing authority and model output

18.1 Rights in submitted material

You must have lawful rights or sufficient authority for prompts, text, data, files and other inputs, and ensure that submission, transmission and use comply with applicable law and obligations owed to relevant rights holders. Possessing material does not necessarily authorise disclosure to an external model service. Before submitting sensitive personal information, trade secrets, confidential material or other protected content, verify the processing basis, permitted scope and safeguards that the circumstances require.

18.2 Limited processing authority

You retain the rights you lawfully hold in user content and grant the Company only the appropriate limited permissions needed to transmit, process, protect, meter and fulfil the relevant service request. This provision is not a transfer of ownership, an unlimited authorisation for public distribution or an independent licence for unrelated use. Processing of personal information and participation of service suppliers are governed by the Privacy Policy and applicable agreements.

18.3 Reviewing and applying output

Model output may be inaccurate, incomplete, outdated, biased or unsuitable for a particular purpose. Apply human review, fact checking, testing and access controls appropriate to the risk, and verify whether quotations, code, data and conclusions can be used in the intended setting. A name, legal provision, professional assessment or reference link appearing in output does not establish that it is accurate, complete or professionally reviewed.

Do not directly rely on model output for medical, legal, credit, employment, safety or other decisions materially affecting individuals without appropriate professional review and necessary safeguards. Adoption, modification, publication and downstream provision of output require the relevant rights and compliance with applicable restrictions. Account permissions, successful metering and fulfilment records respectively reflect authorisation, request handling, metering or delivery. Their evidential scope must be assessed from the contents of the corresponding record.

19. Personal information, local data and user rights

19.1 Governing information-processing document

The Company processes information concerning accounts, authentication, organisations, orders, funds, fulfilment, APIs, devices, diagnostics and support under the KAI Privacy Policy. That Policy describes scope, categories, sources, purposes, sharing, transfers, retention, security and rights requests. References here to account security or audit do not grant a general processing permission beyond the Policy, applicable law or an effective enterprise arrangement.

19.2 Account separation and local storage

Watchlists, recent items, batch templates, settings and local API-credential metadata are scoped to the signed-in account. When switching accounts or signing out, distinguish locally stored information from server records. Clearing a device cache does not mean server records have been deleted, and closing a server account should not be assumed to remove files you exported separately. On shared equipment, appropriately manage downloads, clipboard contents and other copies controlled by the device.

19.3 Deliberate sharing

Before sending information through copying, export or the system share sheet, verify the recipient, scope and your authority. Once sent, information may be controlled by the device, recipient and relevant third-party service. Its origin in KAI does not mean that it remains under our technical control. Do not share full keys, passwords, authentication codes or unnecessary account and funds details. Redact support material in a manner proportionate to the problem being investigated.

You may request access, correction, deletion and other applicable rights through the Privacy Policy process. We may require necessary identity verification to protect the account and handle the request according to its scope and applicable retention requirements. Withdrawing consent to optional processing, disabling a device permission, closing an account and requesting deletion are different matters. A choice may affect the related function without automatically cancelling every existing contractual or statutory record obligation. Any limitation on a rights request remains subject to applicable law.

20. Third-party services, software permission and intellectual property

20.1 Independent service relationships

Apple, Google, device operating systems, networks, email providers, models and other third-party services operate under their own terms, permissions and availability conditions. Except for obligations the Company undertakes in an effective written agreement, we do not control every act of an independent third party. A link or identity mark used to provide a feature or identify a service does not automatically endorse or guarantee all of that party's products, content or business activities.

20.2 Software and information rights

Rights in KAI software, interfaces, marks, documentation, design and information arrangement belong to the Company or the relevant licensors. While complying with applicable conditions, you have a limited, revocable, non-exclusive permission for authorised internal use of the Services. Without appropriate authority, do not turn our branding, interface or materials into a misleading product or represent that you can provide services on our behalf. Rights granted by applicable law or a valid third-party licence are not improperly restricted by this provision.

20.3 Integrations and compatibility

When independently connecting a third-party tool, browser extension or external automation, review the account, information and credential permissions it requests and comply with applicable terms. A tool's ability to connect does not establish that we have reviewed its security or authorised it to administer an account. Changes to operating systems, browsers or third-party services may affect sign-in, notifications or other functions; address compatibility issues using official support information.

If you believe content in the Services infringes your intellectual-property rights, provide the rights holder's or authorised representative's details, a precise location, the basis of the rights claimed and the requested action. Avoid knowingly false claims and unnecessary confidential material. We will address the matter according to applicable law and the relevant facts. A notice does not itself establish infringement or automatically determine final termination of another person's account rights.

21. Amendments, version information and renewed acceptance

21.1 Reasons and version information

We may amend this Agreement to reflect service features, legal requirements, security needs or operational changes and will display the relevant version, revision date and applicable effective information on the public page. Review the version actually presented in the sign-in or authorisation process rather than relying solely on a search summary, an old screenshot or an undated local copy. A revision date and the effective arrangements for a particular change should be interpreted according to the notice expressly supplied for that change.

21.2 Notice of material changes

Material changes will be appropriately brought to your attention through sign-in, the application, the website or your registered email. Where applicable law requires separate or renewed express consent, that requirement will be followed. Merely placing this Agreement on a public page does not replace an additional notice or consent procedure required by law. Authority concerning an optional feature remains subject to the way that feature is actually enabled and the requirements applicable to it.

21.3 If you do not accept an amendment

Continuing to use the Services after a properly notified version becomes effective may constitute acceptance. If you disagree, stop affected use and address outstanding matters through the closure process and Terms of Service. Stopping new use does not discharge existing charges, orders, fulfilment or legal responsibilities, and does not require abandonment of a lawful claim concerning an existing dispute. A separately signed enterprise agreement remains subject to its valid amendment process.

The original effective date identifies when the Agreement first took effect; the revision date and version identify subsequent text. Application of an amendment remains subject to its notice and legal requirements. Updating a page version does not alone establish delivery of notice or renewed consent required by law. If the applicable time, version or scope is unclear, provide available version records and the sign-in time for verification. A correction of presentation, translation or links must not retrospectively alter the core economic conditions of completed business.

22. Access restrictions, review, restoration and account closure

22.1 Reasons for restrictions

False information, unverifiable identity or authority, account sharing, exposed credentials, security risks, breach of applicable documents, legal requirements or outstanding obligations may require restrictions on sign-in or functions, session revocation, suspension of affected actions, or account suspension or termination. The scope of a measure should reflect the risk, affected capabilities and applicable obligations. A functional restriction does not itself alter an actual balance, completed business records or rights provided by law.

22.2 Notice and review

Where law and security permit, we will provide a reason or restoration path. If you believe a restriction is mistaken, send your UID, relevant notice, event time, explanation and necessary evidence from the registered email and request review. Do not circumvent a restriction using a new identity, a borrowed account or continuing retries. Some security details may not be suitable for immediate disclosure in order to protect others and the integrity of an investigation, without displacing information requirements imposed by law.

22.3 Requesting closure

Apply from the registered email to beidou@kai.com. The service team will first contact you through that email within 72 hours. This period concerns initial contact, not completion of account closure, funds settlement, fulfilment or deletion of all information. Identity verification and confirmation of organisational authority may be required. Do not include passwords, authentication codes or full keys in the request.

22.4 Outstanding matters

Open orders, balances, charges, fulfilment, disputes, security investigations and required retention must be addressed before closure is completed. The team will identify matters needing verification or handling as applicable. Sending a request does not automatically cancel orders, sell positions, transfer balances or extinguish accrued responsibility. Closure and personal-information deletion requests have different scopes; necessary records are retained under the Privacy Policy and law. After exit, preserve records required by law or contract and stop using account access that is no longer valid.

23. Service warranties, boundaries of responsibility and risk allocation

23.1 Conditions of account functions

Except where applicable law or an effective written agreement requires otherwise, account and authentication functions are provided on an “as is” and “as available” basis, without a guarantee of uninterrupted, delay-free or error-free operation. The ability to sign in does not establish availability of every business service. Public help information and general support replies do not independently create an unstated availability target, compensation arrangement or specific recovery commitment. An express service commitment remains governed by its applicable document.

23.2 Matters within your control

Take appropriate measures concerning devices, credentials, internal authority, accurate information and instruction review within your reasonable control, and bear the reasonable consequences of failure according to applicable law and agreements. An organisation using employees, contractors or software suppliers should maintain controls proportionate to their authority and the business risk. Delegation does not by itself remove contractual obligations arising from valid instructions.

23.3 Limits and preserved responsibility

The Company's disclaimers and liability limit are governed by the liability provisions of the Terms of Service. Nothing excludes or limits responsibility for fraud, wilful misconduct, gross negligence or liability that applicable law does not permit to be excluded or limited.

Where loss or a dispute occurs, authority, system conditions, notification timing, each party's fault and causation should be assessed on the particular facts. Take reasonable steps to avoid preventable further loss and preserve records needed for assessment; the Company must also perform its applicable obligations. Reporting an incident, restricting an account or assisting an investigation does not automatically admit liability. Interpretation of rights and remedies must preserve protections that cannot lawfully be waived. No account-security recommendation in this Agreement displaces an obligation that the law places on the Company.

24. Governing law, disputes and general provisions

24.1 Law and initial resolution

This Agreement is governed by Hong Kong law, excluding conflict-of-law rules. For an account dispute, first contact the Company from the registered email with your UID, relevant records, requested resolution and effective contact details. The parties will attempt in good faith to resolve the matter within thirty days. This process supports factual review and discussion; it does not guarantee agreement within thirty days or prevent necessary relief that may lawfully be sought promptly.

24.2 Courts and preserved rights

Unresolved disputes are subject to the exclusive jurisdiction of courts of competent jurisdiction in Hong Kong, without affecting a non-waivable forum choice, consumer protection or other mandatory right under applicable law. This Agreement contains no mandatory arbitration requirement or class-action waiver. Internal authority or employment disputes with an organisation must be addressed by the relevant parties under their applicable relationship. Using KAI does not automatically make the Company a party to that internal relationship.

24.3 Supporting records

Describe the facts, timing, affected functions and requested outcome as accurately as possible, distinguish confirmed records from assumptions, and preserve original requests and receipts. Each party should provide necessary relevant material within lawful limits, avoiding unrelated third-party personal information and full authentication secrets. You are not required to continue risky business activity in order to raise a reasonable objection or produce additional examples of a reported problem.

24.4 Separate effect and exercise of rights

If a provision is found invalid or unenforceable, other provisions capable of lawful independent operation remain effective. Any replacement or interpretation must respect applicable law and the lawful purpose of the original arrangement. A party's delay in exercising a right or temporary assistance does not automatically waive that right. Assignment of account access, organisational changes and related contractual transfers are handled under the Terms of Service and effective enterprise agreements. Handing over a password is not a substitute for necessary authority and formal procedures.

25. Contact details, request information and related documents

25.1 Official contact information

VN TECH LTD
1312 17th Street, Suite 769
Denver, Colorado 80202
United States

KAI service operations: Hong Kong
Email: beidou@kai.com
Telephone: 400 108 2026

25.2 Information for an account request

For access, correction, authority changes, unusual activity, closure or a dispute, provide the registered email, UID, request category, event time and a concise factual explanation. For an order, funds or fulfilment outcome, add the original request ID and relevant business identifiers. If acting for an organisation, state your position and the basis of authority. Supply accurate and necessary material; an initial email need not contain complete documents unrelated to the request.

25.3 Confidentiality and verification

Do not send passwords, one-time authentication codes, recovery codes, private keys or full API keys through ordinary email. If other sensitive evidence is required, verify the submission method and necessary scope through an official channel first. Keep your request and subsequent replies so that the matters under review can be identified. An automated acknowledgement or initial response does not mean that recovery, permission changes, funds adjustments or closure have been completed.

This Agreement, the Terms of Service, Privacy Policy, Product Introduction and Help Center together explain accounts and Services and are available through the links below. Asking a question does not affect rights provided by applicable law. A business instruction must still be issued through the authenticated procedure applicable to it; an ordinary enquiry email should not be treated as an already submitted order or instruction to change funds. If a reply requests further clarification, identify the original correspondence so that separate requests are not mistaken for duplicate business instructions.