Non-custodial execution and its limits.

Deal funds are held in a non-custodial smart contract and are handled according to predefined logic. Nexelorant does not take deal funds into intermediary custody. The code does, however, provide for transferring a fee portion to the technical financial address specified in the deal's parameters.

In Nexelorant Account, protected signed operations are verified against the owner's public key. Other handlers have separately defined sender rights: Nexelorant's infrastructure can relay the execution messages the contract provides for. Owner authorization and operator authority are different mechanisms.

Once locked, the assets are governed by the contract's logic. That also means they pass out of your direct control — until the operation reaches an outcome the contract recognizes.

Only by reaching a defined outcome. Depending on the operation, that's successful completion, cancellation, partial redistribution, a timeout refund, settlement under the protocol's rules, or another path written into the contract.

The permitted outcomes are defined by the contract's code. An authorized sender can trigger a scenario the contract provides for, but the settlement parameters and recipients remain bound by that specific contract's logic.

They are built into the contract's execution paths and apply automatically, under the rules of the specific operation. They are never invoiced or deducted by hand.

A settlement or refund path becomes available only when the conditions of the matching handler are met. The mere passage of time does not substitute for a permitted execution message or for the technical checks that must still pass.

The published CPP code has built-in refund and resend paths. Whether one applies depends on the deal's state, the sender's rights, and whether the handler's conditions are met.

A deadline passing does not send funds by itself: the matching path still has to be triggered by a permitted message. Execution also requires the wallet and network-fee budget checks to pass.

For a CPP deal in Affaire, the factory deploys a separate contract with set parameters. This describes the current CPP implementation, not a rule for every operation and every Nexelorant product.

The placement's terms are agreed before execution. The factory accepts a deployment message from its own owner or operator. Actions that require user confirmation in the product are authorized through TON Connect; that is distinct from checking the sender of a message sent to the factory.

The contract locks in the deal's parameters and implements its permitted state transitions and settlements. Authorized messages trigger the handlers it provides for; they do not grant arbitrary changes to the contract's logic.

Nexelorant Account provides for a token transfer to a target address, checked against owner authorization. The CPP contract credits funding only if the notification came from the linked jetton wallet, the token sender matches the advertiser's address in the deal's parameters, and the state allows funding.

In the current public Affaire scenario, settlement runs in USDT. Verified contracts use a set token master and a linked jetton wallet. This describes the current scenario, not a claim that every Nexelorant product supports any token.

A smart contract does not observe the external environment on its own. In the canonical chain, CAT Network supplies the external data, and Nexelorant CAT analyzes it and establishes a factual state that a product can use during execution.

Technical infrastructure delivers the execution messages the contract provides for. The contract checks the sender's rights and its handler's conditions; an authorized operator does not become a second source of the external factual state.

Not every signal is tied to CAT. Cancellation, completion after the holding period, and resending belong to the deal's own lifecycle. These actions cannot automatically be described as the result of analyzing an external event.

Interfaces, transaction preparation, delivering the actions it provides for to the blockchain, fee mechanisms, and Nexelorant's technical execution infrastructure.

All of this exists to coordinate execution within the contract model. None of it is a custody mechanism for funds.

A deal's outcome is decided by the agreed terms and the contract's permitted scenarios. In the published CPP code, completion, cancellation, and refund are all triggered by permitted messages once the matching handler's conditions are met.

Nexelorant is not a legal party to your deal and makes no discretionary decisions about it. Every operation runs inside the execution model the system defined in advance.

The current Affaire offers arbitration with a review period of up to 24 hours. It decides which of the contract's scenarios applies when the parties disagree.

If an objective violation is confirmed, cancellation with a funding refund to the advertiser applies. If the violation is not confirmed, the contract's distribution scenario applies instead. The published CPP code has separate handlers for objective and subjective cancellation in arbitration; neither is the same path as ordinary successful completion.

Once the review period expires, the contract's timeout scenario becomes available. It requires a message from a permitted sender; in the published CPP code, this path refunds the funding to the advertiser. The operator cannot add a new outcome outside the contract's logic.

The existence of a dispute process does not grant unlimited authority over the outcome. Any decision or action stays bound by the settlement paths, rights, and logic available in the contract.

Specifically: we cannot obtain private keys, cannot transfer assets to an arbitrary address, cannot override the contract's execution, and cannot move funds outside the settlement mechanisms the protocol provides.

On-chain, you can verify a specific contract's code and state, its transactions, and its execution results. This data is available on the public The Open Network.

Use any third-party explorer — Tonviewer or similar. Contracts can be independently verified with standard tools — meaning you can check behavior, transaction flow, and outcomes yourself.

We also publish the contract architecture and the source code, so the execution model can be read, not guessed at.

The off-chain context behind a signal. When an action depends on an execution signal sent by the operator, you can verify what the contract did — execution is visible on-chain — but the event that triggered it may not be independently verifiable from blockchain data alone.

This is a real limitation, and it's stated deliberately. Verifiability here means transparency in how execution proceeded; it does not mean the protocol can change that execution.

Confirmed blockchain transactions are final and irreversible. A wrong address, wrong parameters, an unsupported interaction, or a plain mistake can lead to an unrecoverable loss of funds.

Nexelorant cannot cancel, change, override, or reverse a confirmed transaction beyond the mechanisms the contract itself provides. Contacting support does not undo finality.

We also do not control the TON network or third-party services, including explorers, and are not responsible for their availability or accuracy.

Wallet security, managing your private keys, and every action taken from your addresses. A transaction signed and sent from your wallet is treated as fully authorized by you — because cryptographically, it is.

The model is built so that execution is governed by transparent rules, cryptographic authorization, and contract logic — not by the platform holding funds. The flip side: no one can undo your signature either.