Important Notice
This Risk Disclosure document (the "Disclosure") describes certain risks associated with the use of the Carpe Diem Protocol (the "Protocol"). This Disclosure is not exhaustive and does not purport to identify all risks that may arise from the use of the Protocol, its smart contracts, its tokens, or any related services.
Users are solely responsible for conducting their own research, due diligence, and risk assessment before interacting with the Protocol. Nothing in this Disclosure, in the Protocol's whitepaper, documentation, website, or any communication from the Association or its contributors constitutes financial, investment, legal, or tax advice.
By using the Protocol, you acknowledge that you have read, understood, and accepted the risks described herein and in the Terms of Use.
1. Smart Contract Risks
1.1. The Protocol's smart contracts are experimental software deployed on Base Layer 2 (an Ethereum rollup). Despite the use of industry-standard libraries and a comprehensive test suite, smart contracts may contain bugs, vulnerabilities, or unforeseen interactions that could result in partial or total loss of funds deposited in the Protocol.
1.2. The smart contracts employ the UUPS (Universal Upgradeable Proxy Standard) proxy pattern, which allows the contract logic to be upgraded while preserving the contract address and user balances. While this enables the correction of discovered vulnerabilities, it also introduces upgrade risk: a faulty upgrade could compromise the contract's state or render funds inaccessible.
1.3. As of the date of this Disclosure, the Protocol's smart contracts have not been subject to an external security audit. An independent audit will be conducted when the Protocol's financial conditions allow. Until such audit is completed and published, users interact with unaudited smart contracts entirely at their own risk.
1.4. The Protocol relies on third-party smart contracts and decentralized exchange protocols for token swaps. Vulnerabilities or failures in these external contracts could affect the Protocol's settlement and swap operations.
2. Escrow and Credit Risks
2.1. The Protocol operates a credit system where 100 credits equal one United States dollar (USD $1), equivalent to one USDC on-chain. Credits are purchased either by depositing funds into the Protocol's escrow smart contract or by card payment through our payment processor. Card purchases are priced per pack in US dollars and cost more per credit than a USDC deposit. Requests can also be paid one by one from a wallet (x402) or from a prepaid account, without buying credits.
2.2. Credits are non-refundable. Once deposited, funds cannot be withdrawn from the escrow contract, and credits bought by card cannot be converted or withdrawn. Credits can only be consumed through API usage. If a card payment is refunded or reversed, the corresponding credits are removed from your balance, and card purchases may be suspended for your account. This is subject to any mandatory consumer rights in your jurisdiction.
2.3. The value of credits is denominated in USDC. Users bear the risk of any fluctuation in the value of USDC relative to their local currency or other assets.
2.4. Your credit balance is recorded by the Operator, inside the TEE, and not as a balance in the escrow contract; deposits remain recorded on-chain. In the event of a smart contract failure, upgrade error, exploit or loss of the Operator's records, funds or credits may become partially or wholly inaccessible. The Protocol provides no deposit insurance, guarantee of recovery, or compensation mechanism.
2.5. Payment allowances. Paying from a prepaid account or with a wallet session (x402 carpe-session) gives the escrow a standing USDC allowance on your account or wallet. The Operator can draw on it, up to the approved amount, until it is spent or you revoke it. Approve only an amount you are prepared to spend.
3. Trusted Execution Environment (TEE) Risks
3.1. The Protocol's Operator runs within a hardware Trusted Execution Environment (Intel TDX) hosted on Phala Cloud. The TEE is designed to keep provider API keys, user requests and the Operator's database out of reach of the hosting provider. The Association's administrators can read Operator data only through the Operator's authenticated administration endpoints, used for operations and backups.
3.2. These protections rely on the correctness of the TEE hardware, its firmware and the attestation chain, which are provided by third parties (Intel, Phala). Hardware vulnerabilities, side-channel attacks or flaws in the attestation process could expose data held in the TEE.
3.3. Some components run outside the TEE: the website and its payment pages, and the third-party inference markets to which the best-price router may send a request (see Section 6). Data handled by these components does not benefit from TEE protection.
3.4. If the Operator experiences downtime, crashes, or restarts, the service is interrupted until it is restored. Funds remain safe in the on-chain escrow. Provider API keys survive restarts through an encrypted backup, except for providers who opted out of it (RAM-only mode), whose keys are lost on restart and must be re-provisioned.
4. Settlement and Billing Risks
4.1. The Protocol uses an off-chain billing engine that accumulates consumer debt between settlement cycles. Settlement frequency adapts to the total pending debt, with more frequent settlement for larger amounts and less frequent settlement for smaller amounts.
4.2. Between two consecutive settlements, consumed credits have been billed off-chain but not yet settled on-chain. The Operator's records are kept in an encrypted, persistent database with backups; if they were nevertheless lost, balances and pending charges would have to be rebuilt from on-chain deposits and usage records, which could delay service or cause discrepancies.
4.3. While adaptive settlement intervals are designed to minimize this exposure, a small window of unbilled or unsettled consumption always exists. Users should be aware that recent consumption may not be immediately reflected on-chain.
4.4. Settlement transactions involve on-chain gas costs on Base L2. While Base transaction fees are generally low, network congestion or L2 sequencer issues could delay or increase the cost of settlements.
5. Market and Liquidity Risks
5.1. The DIEM token is a freely tradeable digital asset whose market price is subject to significant volatility. The value of DIEM may fluctuate substantially due to market conditions, speculation, regulatory developments, or changes in the Venice.ai ecosystem.
5.2. The Protocol's settlement mechanism converts USDC to DIEM via decentralized exchanges on Base. The availability and depth of liquidity on these exchanges directly affects the execution quality of these swaps.
5.3. Low liquidity conditions may result in significant slippage — the difference between the expected swap rate and the actual rate received. While the Protocol enforces a minimum acceptable DIEM amount per settlement to prevent execution at highly unfavorable rates, slippage within the acceptable range is borne by the settlement and may affect provider revenue.
5.4. There is no guarantee that sufficient DIEM liquidity will exist on decentralized exchanges at any given time. Market conditions, whale activity, or liquidity withdrawal could temporarily or permanently impair the Protocol's ability to execute settlements efficiently.
6. Venice.ai Dependency and Third-Party Markets
6.1. The Protocol currently depends on Venice.ai as its main upstream AI inference provider. Requests served by the Protocol's own network are fulfilled by Venice.ai's infrastructure through provider API keys.
6.2. A change in Venice.ai's terms of service, pricing model, API specifications, or supported models could directly and materially impact the Protocol's operations, pricing, and service availability.
6.3. Venice.ai may, at its sole discretion, revoke or suspend individual API keys used by providers within the Protocol. Such revocation would immediately interrupt service for requests routed through the affected provider, though the Protocol's multi-provider routing may mitigate the impact if alternative providers are available.
6.4. A prolonged or permanent shutdown of Venice.ai's services would render the Protocol unable to fulfill inference requests. In such an event, credits deposited in the escrow would remain locked in the smart contract with no ability to consume them through the Protocol.
6.5. The Protocol does not control, and has no contractual relationship with, Venice.ai that would guarantee continued service availability, pricing stability, or key validity.
6.6. Third-party markets. The best-price router (the /router endpoints, also used by the website's Studio) may send a request to a third-party inference market, such as Surplus, AntSeed, OpenRouter or Chutes, when that market is cheaper or when the Protocol's own network cannot serve it. Such requests are processed outside the TEE, under the market's own terms, availability and content policies, and may be served by providers the Protocol does not select or control. These markets may see and keep the requests they serve: Chutes runs on independent GPU operators, and OpenRouter forwards each request to the model's maker. To keep a request inside the Protocol's own network, use the /v1 endpoints (except the x402 pay-per-request endpoints under /v1/x402/) or set forceMarket to carpe.
7. AI Model Output Risks
7.1. The Protocol proxies requests to large language models and to image, video, speech, music, transcription and embedding models, including voice cloning. Their outputs may be incomplete, incorrect, biased, misleading, or otherwise unreliable.
7.2. Carpe Diem does not control, filter, moderate, or endorse model outputs. The Protocol acts solely as an infrastructure layer that routes requests and relays responses.
7.3. Venice.ai provides access to uncensored inference models. As a consequence, the Protocol may relay content that would be restricted, filtered, or unavailable on mainstream AI platforms. Users are solely responsible for their use of model outputs and for compliance with applicable laws regarding generated content.
7.4. AI-generated content should not be relied upon as a sole source of truth, particularly for decisions with legal, financial, medical, or safety-critical consequences. Users assume all risk associated with their reliance on model outputs.
7.5. The Protocol, the Association, and its contributors accept no liability whatsoever for any loss, damage, or consequence arising from the use of, or reliance on, AI model outputs delivered through the Protocol.
8. Cross-Chain and Swap Risks
8.1. The Protocol supports deposits from any token on any supported blockchain through integration with the LI.FI cross-chain aggregation protocol. Cross-chain transactions involve bridging assets between different blockchains, which introduces additional risk vectors.
8.2. Cross-chain bridges are among the highest-risk components in decentralized finance. Bridge exploits have historically resulted in losses of hundreds of millions of dollars across the industry. While LI.FI aggregates across multiple bridge providers and routes, the underlying bridge infrastructure is outside the Protocol's control.
8.3. Cross-chain swap transactions may fail due to bridge congestion, insufficient liquidity on the destination chain, slippage exceeding tolerance, or smart contract errors in bridge contracts. Failed transactions may result in temporary or permanent loss of funds, depending on the bridge provider's recovery mechanisms.
8.4. Token compatibility and decimal precision across chains may introduce rounding discrepancies. The Protocol is not responsible for losses arising from cross-chain routing failures or bridge-related incidents.
9. Provider-Specific Risks
9.1. Providers who contribute their Venice API keys to the Protocol do so voluntarily. By provisioning a key, the provider grants the Protocol's TEE the ability to use that key to fulfill consumer requests.
9.2. Plaintext provider API keys are stored exclusively in volatile memory (RAM) within the operator's TEE. By default, an AES-256-GCM encrypted backup is persisted to disk for reboot resilience; Providers may opt out of this backup (RAM-only mode). If a Provider has opted out, their key is irreversibly lost upon any server restart, crash, or maintenance and must be re-submitted.
9.3. Provider revenue depends on the volume of traffic routed through their API key by the Protocol's routing algorithm. There is no guarantee of any minimum traffic, revenue, or utilization. The routing algorithm distributes requests across all active providers based on performance metrics, and a provider's share may vary significantly over time.
9.4. Providers receive revenue in DIEM tokens for requests served through the Protocol, and in USDC for sales made on third-party markets. The fiat value of DIEM revenue is subject to the market price of DIEM at the time of claiming and any subsequent price movements. Providers bear full market risk on their accumulated and unclaimed DIEM.
9.5. Providers remain subject to Venice.ai's terms of service. If Venice determines that a provider's key is being used in violation of its terms, the key may be revoked, and the provider may face consequences under Venice's policies.
9.6. Selling on Surplus. A provider who enables sales on the Surplus marketplace authorizes the creation of a dedicated Venice API key on the provider's Venice account. That key leaves the TEE: Surplus holds it, encrypted, and uses it to serve its own buyers directly. At worst, it can consume the provider's daily DIEM allowance. Surplus's terms, payout schedule and reliability apply. A minimum stake is required, and sale prices follow a daily rule set by the Protocol.
9.7. Surplus earnings are claimed automatically and regularly, and paid in USDC to the provider's revenue-splitter contract, which keeps a 10% fee before the provider can claim the rest. This rate is fixed in the splitter contract and cannot be changed in an existing splitter. A different rate would require new splitter contracts, deployed by a new factory contract, to which future earnings would be paid only after at least 14 days' notice (Terms of Use, Section 6.6); funds already in an existing splitter keep its 10% rate. Payouts depend on Surplus actually paying, which the Protocol cannot guarantee.
9.8. Venice may hold data on a provider's account as a result of serving requests, for example voice samples uploaded for voice cloning, which Venice keeps for 7 days.
10. Token Risks
10.1. The DIEM token is a digital asset with no intrinsic value and no guarantee of future value. Its price is determined solely by market supply and demand on decentralized exchanges.
10.2. The DIEM token has an inflationary supply mechanism with periodic emission. New token issuance dilutes existing holders' proportional ownership. There is no guarantee that demand growth will offset emission-driven supply increases.
10.3. Providers who accumulate DIEM through the Protocol may create sell pressure when claiming and liquidating their earnings. Large or coordinated sell events could materially impact the token's market price.
10.4. The Protocol's settlement mechanism generates constant buy pressure on DIEM through USDC→DIEM swaps. However, this buy pressure depends entirely on continued Protocol usage. A decline in usage would reduce buy pressure and could negatively affect the token price.
10.5. Tokens may be subject to regulatory classification as securities, utility tokens, or other regulated instruments depending on the jurisdiction. Users are solely responsible for determining the legal status of tokens in their jurisdiction.
11. Dynamic Pricing Risks
11.1. The per-request cost on the Protocol is not fixed. It is determined dynamically based on current utilization across the provider pool, using a mathematical pricing function.
11.2. Prices on the Protocol's own network range between approximately 15% and 100% of Venice.ai's direct rates. There is no guarantee of any specific price at any given time. The price may change between the time a request is initiated and the time it is billed.
11.3. During periods of high demand or low provider availability, prices may approach or reach 100% of Venice's direct rates, eliminating the cost advantage of using the Protocol.
11.4. The price of each request varies continuously by design. The fee structure — the surcharge rate, the routing fee on third-party markets, the rate of credits per US dollar and the fee kept by revenue-splitter contracts — may be modified through smart contract upgrades, new smart contracts or Operator configuration changes, with the advance notice set out in the Terms of Use (Section 6.6).
11.5. Requests served by a third-party market through the best-price router are billed at that market's own price, which is independent of Venice.ai's rates, plus a routing fee (currently 20% of the market's price) and, for a market the Protocol pays in advance (currently Chutes), the cost of that advance funding (currently 6%). They may cost more than Venice.ai's direct rate.
12. Regulatory and Legal Risks
12.1. The regulatory framework applicable to decentralized finance protocols, AI inference services, and digital assets is evolving rapidly and differs significantly across jurisdictions. Legislative or regulatory changes could restrict, prohibit, or impose new compliance obligations on the Protocol's operations.
12.2. Emerging AI regulations (including but not limited to the EU AI Act and similar frameworks) may impose content moderation, transparency, or compliance requirements that conflict with the Protocol's decentralized and uncensored architecture.
12.3. Tax treatment of digital assets, DeFi transactions, and AI service credits varies by jurisdiction and may change. Users are solely responsible for understanding and complying with their tax obligations arising from Protocol use.
12.4. The Protocol is operated by an association governed by Swiss law. Users in other jurisdictions may face uncertainty regarding the enforceability of their rights, applicable consumer protections, or available legal remedies.
13. Privacy and Data Risks
13.1. Usage records identify consumers by a keyed hash of their wallet address; other records keep the wallet address itself (see the Privacy Policy). This is pseudonymization, not anonymization. On-chain transactions (deposits, settlements) are publicly visible on the Base blockchain and can be linked to wallet addresses.
13.2. The Operator's database is stored on encrypted, persistent storage inside the TEE, and encrypted backups are periodically written. The security of this data depends on the integrity of the TEE, the encryption implementation and key management.
13.3. On-chain activity is permanently recorded on the blockchain and cannot be deleted, modified, or made private after the fact. Users should be aware that their deposit and settlement history is publicly and permanently accessible.
13.4. The Protocol collects minimal data necessary for operation. However, metadata associated with API requests (timing, model selection, token counts) may reveal patterns about a user's activity even in pseudonymized form.
13.5. Requests routed to third-party markets, and voice samples uploaded for voice cloning, leave the TEE and are processed by third parties under their own policies (see the Privacy Policy).
13.6. Access to an email account relies on access to the mailbox: anyone who controls your mailbox can sign in to your account and use its credits.
14. Operational Risks
14.1. During the incubation phase, the Protocol depends on a small core team for all aspects of operation, including server management, smart contract administration, key provisioning oversight, and software updates.
14.2. The Operator currently runs as a single instance, and the website on a single server, with no geographic redundancy or automated failover. A hardware failure, network outage, or hosting provider issue would result in service interruption until manually resolved.
14.3. Smart contract administration (upgrades, pause/unpause, role management) is controlled by a limited set of administrative keys. Loss, compromise, or unavailability of these keys could impair the Protocol's ability to respond to emergencies or perform necessary upgrades.
14.4. The source code of the Protocol's main smart contracts — the escrow contract, the provider revenue splitters and their factory — is published and verified on Sourcify. The Operator's and the website's source code is not public: users cannot inspect it themselves and rely on the TEE attestation, which proves which software image runs but not what it does, and on the Association's statements.
15. No Insurance or Guarantee
15.1. No deposit insurance. Funds deposited in the Protocol's escrow contract are not insured by any government agency, deposit insurance scheme, or private insurer. There is no guarantee of recovery in the event of loss.
15.2. No uptime guarantee. The Protocol is provided without any service level agreement. There is no guaranteed minimum uptime, response time, or availability.
15.3. No guaranteed returns. Neither consumers nor providers are guaranteed any specific financial outcome from using the Protocol. Past performance, pricing, or revenue is not indicative of future results.
15.4. No external audit (as of this date). The Protocol's smart contracts have not yet been audited by an independent third-party security firm. Users interact with unaudited code at their own risk.
15.5. No warranty. The Protocol is provided "as is" and "as available," without warranty of any kind, express or implied. See the Terms of Use for the complete disclaimer.
16. Acknowledgment
By using the Carpe Diem Protocol in any capacity — as a consumer, provider, token holder, or otherwise — you acknowledge and accept all of the risks described in this Disclosure, as well as any additional risks not specifically identified herein.
You confirm that you have the financial knowledge and experience to evaluate the risks of using the Protocol, that you can afford the potential loss of any funds deposited, and that you have sought independent professional advice where appropriate.
This Disclosure should be read in conjunction with the Terms of Use, which govern your use of the Protocol.
This document may be updated from time to time. Continued use of the Protocol after any update constitutes acceptance of the revised Disclosure.