Client financial assurance
Project specific financial protection linked to clearly documented obligations
A distinguishing element of the XCusty proposition is the ability to structure financial assurance for qualifying client engagements. The arrangement can involve dedicated collateral and a staking-pool mechanism associated with smart contract activation. Its purpose is to define financial support for specific obligations alongside the technical delivery agreement.
The QCP arrangement
For an engagement involving QCP, the intended structure is a client-specific assurance arrangement established when the relevant smart contract is activated. QCP's participation, exact role and any financial obligation require its separate written acceptance. The applicable documents identify the contracting entities and specify who provides the guarantee or collateral.
An executed guarantee must define its beneficiary, covered obligations, maximum amount, validity period and claims process. A reference to QCP or the deployment of a smart contract does not itself create a guarantee from QCP.
Collateral and staking serve different purposes
Collateral is an asset committed to support an obligation under agreed terms. Protocol staking places assets into a network validation or related arrangement and may expose them to additional risks. A pool may contain locked collateral without performing protocol staking; the actual mechanism must therefore be specified.
If staking is used, the design addresses withdrawal delays, price movements, validator penalties and smart contract dependencies. Expected staking rewards are not a substitute for available collateral or a defined repayment obligation.
Client visibility
The client should be able to understand what protection exists, the assets supporting it, who controls those assets and what evidence is needed to make a claim. Reporting and contract permissions are designed around those requirements.
The final structure is agreed case by case. Coverage, fees, exclusions and release conditions appear in the relevant agreement. Protection is limited to those agreed terms and does not imply blanket protection against market losses or every operational event.
Technical context on pooled staking and its risks
Structuring the assurance arrangement
Make the protection measurable before a client relies on it
The assurance workstream runs alongside technical discovery and commercial contracting. Its output is a structure that the client, XCusty and any participating financial counterparty can evaluate on the same terms.
| Design element | Requirement to settle in the agreement |
|---|---|
| Covered obligation | The precise delivery or payment obligation being supported |
| Responsible parties | Issuer, beneficiary, collateral owner, custodian and administrator |
| Amount and assets | Coverage cap, eligible collateral, valuation rules and replenishment terms |
| Asset control | Holding location, signing permissions and restrictions on reuse |
| Claims | Trigger events, evidence requirements, review authority and payment timing |
| Duration and release | Start date, expiry, milestones and conditions for collateral release |
| Failure handling | Shortfall response, disputes, outages and recovery arrangements |
Establish and verify
Before activation, the parties confirm the signed terms and establish the agreed collateral or pool arrangement. Technical checks can verify the contract configuration, asset balances and permission settings. Legal and financial verification are performed by the parties appointed for those roles.
Monitor during the engagement
Monitoring may include collateral value, coverage level, pool status and upcoming release events. If values can fluctuate, the agreement defines when a shortfall occurs, who must replenish it and what happens if replenishment does not take place.
Claim or release under the agreed rules
A claim follows the defined evidence and decision process. Some triggers may be automated; others require a documented determination by an authorized party. Disputed off-chain events should have an explicit resolution mechanism rather than relying on a smart contract to determine facts it cannot observe.
At completion or expiry, collateral is released according to the documented conditions. Any continuing obligation is identified before release so that the protection period and the delivery commitments remain aligned.