Technical documentation (Annex VII structure)
Product: COOK version 2.0.0
Manufacturer: Bilal El Homsi
Generated: 2026-10-24 by cra-dossier 0.1.0 from the repository cook at commit cd17b114fbab
Regulation: Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 2024/2847, 20.11.2024, http://data.europa.eu/eli/reg/2024/2847/oj
DRAFT generated from the repository for the manufacturer to review, complete and sign. This is not legal advice. This document makes no claim that the product conforms to Regulation (EU) 2024/2847 and no claim about CE marking; conformity is declared only by the manufacturer, on its sole responsibility, after completing the human items in the gap list.
Article 31(1): the technical documentation contains all relevant data or details of the means used by the manufacturer to ensure that the product and the manufacturer's processes comply with Annex I, and at least the elements of Annex VII. Article 31(2): drawn up before placing on the market and continuously updated during the support period. Article 13(13): kept for at least 10 years after placing on the market or for the support period, whichever is longer.
1. General description of the product (Annex VII, point 1)
1(a) Intended purpose
COOK lets a Seeker phone owner type a thought or pick a photo, receive an AI-generated meme character with a meme and sticker pack, and, only if the user chooses, launch that character as a Solana meme coin through one of four launch rails (the COOK Kitchen on Meteora's dynamic bonding curve, Pump.fun, Jupiter Studio or Bags). The app never holds private keys: every transaction is signed by the user's Seed Vault wallet through the Solana Mobile Wallet Adapter. It is distributed through the Solana dApp Store to consumers.
Essential functionalities: AI character and sticker generation from a prompt or a photo; a name check against existing tokens; coin creation and first buy through the selected rail, signed in the user's wallet; a public feed of coins created in the Kitchen with a grade computed by the COOK worker from on-chain facts; an earnings screen where a creator can claim accrued fees; sharing of generated images.
Users: consumers. Security environment provided by the manufacturer: Runs on a Solana Seeker (Android) obtained from the Solana dApp Store, which verifies the package signature on install and update. Keys live in the phone's Seed Vault; the app receives signatures only. Network access is over HTTPS to Solana RPC endpoints, the COOK metadata and feed worker (Cloudflare), the launch-rail APIs and an AI model gateway. The user is responsible for the device lock, for keeping the phone and the app updated, and for approving each transaction in the wallet sheet.
Reasonably foreseeable use and misuse (Article 3(24) and 3(25)): A malicious or tampered build distributed outside the dApp Store; Compromise of the worker or its upload token leading to altered metadata; A vulnerable third-party SDK (bonding curve, wallet adapter, web3) in the dependency tree; Prompt or name-check abuse to produce offensive or infringing coins (handled by the guard data and the grader); RPC endpoint outage or rate limiting causing failed or stuck launches; Phishing through look-alike apps or deep links imitating the wallet sheet
1(b) Versions of software affecting compliance with the essential requirements
| Identifier | Value | Source |
|---|---|---|
| npm package name | cook |
package.json |
| expo slug | cook |
app.json |
| android package | fun.cook.app |
app.json |
| android versionCode | 32 |
app.json |
| gradle applicationId | fun.cook.app |
android/app/build.gradle |
| gradle versionName (native project file; a managed build may override it) | 0.1.0 |
android/app/build.gradle |
| gradle versionCode (native project file; a managed build may override it) | 1 |
android/app/build.gradle |
| documentation covers | 2.0.0 (versionCode 32, live on the dApp Store since 2026-10-09) and later patch builds that are not substantial modifications; the Kitchen fee model changed in 2.0 (build 32), which the manufacturer treats as the version this documentation covers. | answers |
| repository state | branch cook-2.0, 480 commits, last commit 2026-10-15, last tag v2.0.4-rc, uncommitted changes present at scan time |
git |
1(c) Hardware photographs or illustrations
Not applicable: software-only product (Article 13(4) justification: there is no hardware whose external features, marking or internal layout could be shown).
1(d) User information and instructions (Annex II)
Drafted in 05_user_information.md; to be published with the product (Article 13(18)).
2. Design, development, production and vulnerability handling (Annex VII, point 2)
2(a) Design and development, system architecture
A single Expo / React Native Android app (TypeScript, Hermes runtime) with screens for creation, feed, earnings and settings. src/services holds the wallet adapter integration, the Solana connection with RPC failover, the four launch rails behind a registry (src/services/rails), the chain-facts reader and the worker client. A separate Cloudflare Worker (worker/) owned by the manufacturer stores metadata and images in KV, runs the name check and the launch grader on a schedule, and serves the feed over HTTPS. Images chosen by the user are uploaded to the worker for the coin metadata only when the user launches a coin.
Components (from the answers):
- Mobile app (Expo SDK 57, React Native 0.86, Hermes): UI, wallet adapter client, rail registry, chain-facts reader
- COOK worker (Cloudflare Workers + KV): metadata and image hosting, name check, launch grader, feed
- Solana Mobile Wallet Adapter: signing in the Seed Vault wallet, outside the app
- Launch rails (third-party on-chain programs and APIs): Meteora dynamic bonding curve, Pump.fun, Jupiter Studio, Bags
- Model gateway (third party) for character, meme and sticker generation
Data flows: Prompt text or a user-chosen image goes to the model gateway through the worker to generate the character; the result is shown on the device. On launch, the coin metadata and image are uploaded to the worker (KV) and the transaction is built in the app, signed in the wallet and sent to a Solana RPC endpoint. The worker reads public chain data to grade launches. On the device, a small amount of state (hidden coins, settings) is kept in expo-secure-store; no account, password or private key is stored by the app.
External services reached by the code (hosts found in source; query strings and paths removed):
| Host | Occurrences | Cleartext | Example file |
|---|---|---|---|
| cookkitchen.fun | 25 | no | dapp-store/config.yaml |
| api.devnet.solana.com | 9 | no | scripts/check-fees.cjs |
| pump.fun | 6 | no | src/facts.ts |
| solscan.io | 5 | no | scripts/claim-cook-fees.cjs |
| openrouter.ai | 4 | no | docs/namecheck/mild/check.mjs |
| cook-metadata.bcrypto-eth.workers.dev | 4 | no | scripts/measure-tx-size.ts |
| arxiv.org | 3 | no | src/facts.ts |
| api.mainnet-beta.solana.com | 2 | no | scripts/sim-kitchen-v2.ts |
| solana-rpc.publicnode.com | 2 | no | src/config.ts |
| jup.ag | 2 | no | src/copy.ts |
| api.llama.fi | 2 | no | src/facts.ts |
| api.jup.ag | 2 | no | src/services/chainFacts.ts |
| www.jitpack.io | 1 | no | android/build.gradle |
| api.cloudflare.com | 1 | no | scripts/views-people.cjs |
| api.mainnet.solana.com | 1 | no | src/config.ts |
| app.meteora.ag | 1 | no | src/screens/EarningsScreen.tsx |
| public-api-v2.bags.fm | 1 | no | src/services/rails/bags.ts |
| api.geckoterminal.com | 1 | no | worker/src/cron/poolnames.js |
| query.wikidata.org | 1 | no | worker/src/cron/trends.js |
| api.dexscreener.com | 1 | no | worker/src/cron/trends.js |
| www.geckoterminal.com | 1 | no | worker/src/cron/trends.js |
| dexscreener.com | 1 | no | worker/src/cron/trends.js |
| api.telegram.org | 1 | no | worker/src/lib/alert.js |
| www.wikidata.org | 1 | no | worker/src/lib/wikidata.js |
| cdn.jsdelivr.net | 1 | no | worker/src/routes/upload.js |
Third-party services relied on (Article 13(5) due diligence; guidance C(2026) 5252 section 7.3): Solana RPC (public endpoints and a paid provider) (read chain state, send signed transactions); Meteora dynamic bonding curve program and SDK (Kitchen launches and fee claims); Pump.fun, Jupiter, Bags (alternative launch rails chosen by the user); OpenRouter (model gateway for image and text generation, called by the worker); Cloudflare Workers and KV (hosts the COOK worker (remote data processing solution))
Permissions and platform capabilities: Android permissions android.permission.CAMERA, android.permission.INTERNET, android.permission.SYSTEM_ALERT_WINDOW, android.permission.READ_EXTERNAL_STORAGE, android.permission.RECORD_AUDIO, android.permission.VIBRATE, android.permission.WRITE_EXTERNAL_STORAGE; explicitly blocked: android.permission.RECORD_AUDIO, android.permission.SYSTEM_ALERT_WINDOW; Expo plugins: expo-image-picker, expo-secure-store, expo-sharing, expo-font.
2(b) Vulnerability handling processes
- Software bill of materials:
sbom.cdx.json(CycloneDX 1.7, 814 components, 29 top-level, generated by cdxgen on 2026-10-24). Annex I, Part II, point (1). - Coordinated vulnerability disclosure policy:
SECURITY.md(draft) [HUMAN: publish it and record the URL]. Annex I, Part II, point (5). - Contact address for vulnerability reports: hello@cookkitchen.fun;
security.txt(draft) [HUMAN: serve it at /.well-known/security.txt]. Annex I, Part II, point (6); Article 13(17). - Secure distribution of updates: New builds are produced with EAS Build, signed with the manufacturer's upload key, submitted to the Solana dApp Store publisher portal and installed or updated by the dApp Store client on the phone; the worker is deployed with wrangler and versioned with rollback targets. Annex I, Part II, point (7).
- Vulnerability handling procedure:
04_vulnerability_handling.md.
2(c) Production and monitoring processes and their validation
Build and release: npm run check, test scripts for rails, guard and screens, EAS production build, device test on a physical Seeker, upload to the dApp Store portal with release notes; worker deployed with wrangler deploy --tag and a recorded rollback version.
Development process: Single developer with Claude Code sessions; TypeScript with tsc --noEmit, a copy check and guard-data sync in npm run check; adversarial review rounds recorded in the repository docs; keys kept in .env and never committed (.gitignore covers .env).
Testing: node --test suites for the worker (about 2,000 tests), rail and screen test scripts, device verification before every store submission; no continuous integration service is configured in the repository.
Monitoring after release: Worker health endpoint and wrangler tail; store reviews and the support mailbox; on-chain fee and launch checks; no crash-reporting SDK in the app.
3. Cybersecurity risk assessment (Annex VII, point 3; Article 13(2) to (4))
See 03_risk_assessment.md. Summary of how each Annex I, Part I, point (2) requirement is applicable (Article 13(3)):
| Requirement | Short | Status | How it is applied or why not |
|---|---|---|---|
| Annex I, Part I, point (1) | Appropriate level of cybersecurity based on the risks | Partly shown | A risk assessment input exists (answers or a security policy text). The appropriate level of cybersecurity is a judgment the manufacturer documents in the risk assessment (Article 13(2) and (3)). |
| Annex I, Part I, point (2)(a) | No known exploitable vulnerabilities at release | Not found | 59 known vulnerability advisories affect 21 components in the SBOM (OSV, 2026-10-23); 0 of them are in components the SBOM marks as required (likely shipped), the rest in optional or build-time components. Each needs triage: exploitable in this product or not, and if yes, fixed before release. |
| Annex I, Part I, point (2)(b) | Secure by default configuration, with reset to original state | Manufacturer decision | No cleartext endpoints found. Whether the shipped defaults are secure, and how the user resets the product to its original state, is a manufacturer statement. |
| Annex I, Part I, point (2)(c) | Security updates, automatic where applicable, with notification and opt-out | Partly shown | Updates are delivered through Solana dApp Store; on Android and iOS the store applies updates automatically by default on the user’s device with a user-controlled opt-out, and notifies the user. An in-app version check or update prompt was found. Whether security updates ship separately from feature updates (Annex I, Part II, point (2)) is a process statement. |
| Annex I, Part I, point (2)(d) | Protection from unauthorised access; report possible unauthorised access | Partly shown | Access-control mechanisms were found (bearer token sent to a service; Mobile Wallet Adapter / wallet signing (Solana); API key header sent to a service). Whether they cover every protected function and whether possible unauthorised access is reported is for the manufacturer to confirm. |
| Annex I, Part I, point (2)(e) | Confidentiality of stored, transmitted or processed data (encryption at rest and in transit) | Partly shown | 25 external hosts are reached over https:// and 0 over http://. Encrypted secure storage is used for some data. |
| Annex I, Part I, point (2)(f) | Integrity of data, commands, programs and configuration; report corruptions | Partly shown | Solana dApp Store verifies the package signature on install and update, which protects program integrity; integrity of stored data and configuration against unauthorised modification is for the manufacturer to describe. |
| Annex I, Part I, point (2)(g) | Data minimisation | Manufacturer decision | 7 Android permissions declared (android.permission.CAMERA, android.permission.INTERNET, android.permission.SYSTEM_ALERT_WINDOW, android.permission.READ_EXTERNAL_STORAGE, android.permission.RECORD_AUDIO, android.permission.VIBRATE, android.permission.WRITE_EXTERNAL_STORAGE); 4 device-capability packages; no analytics or crash-reporting SDK found. |
| Annex I, Part I, point (2)(h) | Availability of essential functions, including after an incident and against denial of service | Partly shown | Rate limiting or throttling code was found. |
| Annex I, Part I, point (2)(i) | Minimise negative impact on other devices or networks | Manufacturer decision | Whether the product can degrade other devices or networks (traffic volume, broadcast behaviour, background work) is a design statement. |
| Annex I, Part I, point (2)(j) | Limited attack surfaces, including external interfaces | Partly shown | External interfaces found: 25 remote hosts, 7 permissions, 2 permissions explicitly blocked. Deep links and intents are an external interface on mobile apps; list every scheme and intent filter. |
| Annex I, Part I, point (2)(k) | Exploitation mitigation mechanisms | Manufacturer decision | Mobile platforms provide sandboxing, memory-safe runtimes and signed packages; which of these the product relies on, and what it adds (least privilege, no dynamic code loading, pinned dependencies), is a statement. |
| Annex I, Part I, point (2)(l) | Security-related logging and monitoring with a user opt-out | Partly shown | Logging or telemetry code found (console logging; opt-out or telemetry setting); an opt-out setting was found. Security-relevant events (access to or modification of data, services or functions) need recording with an opt-out mechanism for the user. |
| Annex I, Part I, point (2)(m) | Secure and easy permanent removal of all data and settings | Partly shown | A data-deletion or reset flow was found; confirm it removes all data and settings permanently, including server-side data. |
4. Support period information (Annex VII, point 4; Article 13(8))
See 06_support_period.md. Declared end of support: [HUMAN: YYYY-MM].
5. Standards applied or solutions adopted (Annex VII, point 5)
No harmonised standard with a reference published in the Official Journal, no common specification and no European cybersecurity certification scheme has been applied. As Annex VII, point 5 allows in that case, the solutions adopted to meet Annex I, Parts I and II, are described per requirement below and in the risk assessment. Presumption of conformity under Article 27 is therefore not claimed.
| Requirement | Short | Status | Solution adopted or gap |
|---|---|---|---|
| Annex I, Part I, point (1) | Appropriate level of cybersecurity based on the risks | Partly shown | A risk assessment input exists (answers or a security policy text). The appropriate level of cybersecurity is a judgment the manufacturer documents in the risk assessment (Article 13(2) and (3)). |
| Annex I, Part I, point (2)(a) | No known exploitable vulnerabilities at release | Not found | 59 known vulnerability advisories affect 21 components in the SBOM (OSV, 2026-10-23); 0 of them are in components the SBOM marks as required (likely shipped), the rest in optional or build-time components. Each needs triage: exploitable in this product or not, and if yes, fixed before release. |
| Annex I, Part I, point (2)(b) | Secure by default configuration, with reset to original state | Manufacturer decision | No cleartext endpoints found. Whether the shipped defaults are secure, and how the user resets the product to its original state, is a manufacturer statement. |
| Annex I, Part I, point (2)(c) | Security updates, automatic where applicable, with notification and opt-out | Partly shown | Updates are delivered through Solana dApp Store; on Android and iOS the store applies updates automatically by default on the user’s device with a user-controlled opt-out, and notifies the user. An in-app version check or update prompt was found. Whether security updates ship separately from feature updates (Annex I, Part II, point (2)) is a process statement. |
| Annex I, Part I, point (2)(d) | Protection from unauthorised access; report possible unauthorised access | Partly shown | Access-control mechanisms were found (bearer token sent to a service; Mobile Wallet Adapter / wallet signing (Solana); API key header sent to a service). Whether they cover every protected function and whether possible unauthorised access is reported is for the manufacturer to confirm. |
| Annex I, Part I, point (2)(e) | Confidentiality of stored, transmitted or processed data (encryption at rest and in transit) | Partly shown | 25 external hosts are reached over https:// and 0 over http://. Encrypted secure storage is used for some data. |
| Annex I, Part I, point (2)(f) | Integrity of data, commands, programs and configuration; report corruptions | Partly shown | Solana dApp Store verifies the package signature on install and update, which protects program integrity; integrity of stored data and configuration against unauthorised modification is for the manufacturer to describe. |
| Annex I, Part I, point (2)(g) | Data minimisation | Manufacturer decision | 7 Android permissions declared (android.permission.CAMERA, android.permission.INTERNET, android.permission.SYSTEM_ALERT_WINDOW, android.permission.READ_EXTERNAL_STORAGE, android.permission.RECORD_AUDIO, android.permission.VIBRATE, android.permission.WRITE_EXTERNAL_STORAGE); 4 device-capability packages; no analytics or crash-reporting SDK found. |
| Annex I, Part I, point (2)(h) | Availability of essential functions, including after an incident and against denial of service | Partly shown | Rate limiting or throttling code was found. |
| Annex I, Part I, point (2)(i) | Minimise negative impact on other devices or networks | Manufacturer decision | Whether the product can degrade other devices or networks (traffic volume, broadcast behaviour, background work) is a design statement. |
| Annex I, Part I, point (2)(j) | Limited attack surfaces, including external interfaces | Partly shown | External interfaces found: 25 remote hosts, 7 permissions, 2 permissions explicitly blocked. Deep links and intents are an external interface on mobile apps; list every scheme and intent filter. |
| Annex I, Part I, point (2)(k) | Exploitation mitigation mechanisms | Manufacturer decision | Mobile platforms provide sandboxing, memory-safe runtimes and signed packages; which of these the product relies on, and what it adds (least privilege, no dynamic code loading, pinned dependencies), is a statement. |
| Annex I, Part I, point (2)(l) | Security-related logging and monitoring with a user opt-out | Partly shown | Logging or telemetry code found (console logging; opt-out or telemetry setting); an opt-out setting was found. Security-relevant events (access to or modification of data, services or functions) need recording with an opt-out mechanism for the user. |
| Annex I, Part I, point (2)(m) | Secure and easy permanent removal of all data and settings | Partly shown | A data-deletion or reset flow was found; confirm it removes all data and settings permanently, including server-side data. |
| Annex I, Part II, point (1) | Identify and document vulnerabilities and components; machine-readable SBOM of at least top-level dependencies | Evidence found | SBOM generated: 814 components (29 top-level) in CycloneDX 1.7 JSON by cdxgen. Platform-native dependencies (Gradle, CocoaPods) are not in this SBOM unless the tool resolved them. |
| Annex I, Part II, point (2) | Address and remediate vulnerabilities without delay; security updates separate from feature updates where feasible | Manufacturer decision | No automated dependency update configuration found. The remediation process is a written procedure. |
| Annex I, Part II, point (3) | Effective and regular security tests and reviews | Partly shown | 94 test files, 16 test or check scripts, 0 CI workflows. Security-specific tests and reviews (dependency audit, static analysis, penetration test, code review) were not found. |
| Annex I, Part II, point (4) | Publicly disclose fixed vulnerabilities (description, affected product, impact, severity, remediation) | Partly shown | Release notes or a changelog exist; security fixes need their own entries with description, affected versions, impact, severity and remediation. |
| Annex I, Part II, point (5) | Coordinated vulnerability disclosure policy, in place and enforced | Not found | No coordinated vulnerability disclosure policy was found. A draft is included (SECURITY.md). |
| Annex I, Part II, point (6) | Facilitate vulnerability information sharing; contact address for reports | Partly shown | A security contact address exists in the repository or the answers; publish it where users and researchers can find it (security.txt, the store listing, the website). |
| Annex I, Part II, point (7) | Secure update distribution mechanism, automatic where applicable | Partly shown | Solana dApp Store distributes signed packages; describe the signing keys, their protection, and the path for an urgent security update. |
| Annex I, Part II, point (8) | Security updates disseminated without delay, free of charge, with advisory messages | Partly shown | Updates through an app store or package registry are free of charge to users by default; the advisory message that accompanies a security update is a process the manufacturer runs. |
6. Test reports (Annex VII, point 6)
94 automated test files exist in the repository. [HUMAN: attach the reports of the tests that verify the Annex I requirements: dependency vulnerability check output per release (sbom_vulnerabilities.md), static analysis, security review notes, any penetration test]
7. Copy of the EU declaration of conformity (Annex VII, point 7)
07_declaration_of_conformity_DRAFT.md, unsigned until the gap list is closed.
8. Software bill of materials (Annex VII, point 8)
sbom.cdx.json, provided to a market surveillance authority on reasoned request.