Add Cavos under Smart Account & Authentication

[adrianvrj]

Summary

Re-opens the Cavos listing in skills/standards/ecosystem.md (previously #112).

Cavos is an embedded self-custodial wallet SDK. Stellar accounts are classic G… addresses. @cavos/kit accepts network: "testnet" | "mainnet" on Stellar.

This addresses the review on #112:

• Custody wording matches src/chains/stellar/keys.ts / datamap.ts: the P-256 device key never leaves the device; the ed25519 control seed is sealed into on-chain data entries (cv:ct) and is the transaction signer.
• One-line description. No Twitter/X or Package fields.
• Official-catalog bar: Stellar is live on testnet and mainnet. The 0.1.9 README caveat ("production launch still requires operational, security, and relayer hardening") was about the removed Soroban C… prototype and is gone as of @cavos/kit 0.1.10 / 0.1.11.
• Optional hardware-isolated recovery (AWS Nitro) is listed as a UX feature: recover a new device by signing in again. It is not a transaction signer and cannot move funds. Docs: https://docs.cavos.xyz/docs/hardware-isolated-recovery
• Agent docs: https://docs.cavos.xyz/llms-full.txt

Links

• Site: https://cavos.xyz
• Docs: https://docs.cavos.xyz
• Demo: https://demo.cavos.xyz
• GitHub: https://github.com/cavos-labs/kit

[kaankacar]

🤖 Automated message from Kaan's Automated Triage Bot.

👀 Picked this up — a review will follow shortly.

[Copilot]

Pull request overview

Adds Cavos to the Stellar ecosystem catalog under smart accounts and authentication.

Changes:

• Documents Cavos’s Stellar key and custody model.
• Adds official resources, use case, recovery, and sponsorship features.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

skills/standards/ecosystem.md:200

• The recovery flow itself does sign: approveThisDeviceWithSocialWrap() decrypts the control key and approveThisDevice() uses it to sign and submit the MANAGE_DATA write that enrolls the new device. The intended boundary is that the enclave does not sign transactions, so state that explicitly rather than saying the whole flow “does not sign.”

  - Optional AWS Nitro enclave recovery: new device by signing in again. Intended flow rewraps the DEK to the new device and does not sign; on Stellar the measured enclave and KMS stay in the trust model

[kaankacar]

🤖 Automated message from Kaan's Automated Triage Bot.

Thanks for coming back to this, and for the fast turn on the enclave bullet — it reads honestly now. I checked it against your own docs: "What the chain enforces" says the enclave seals the DEK, ECIES-wraps it to the new device, never receives the control seed, and that Stellar classic cannot enforce its scope or timelock on-chain. Both llms links return 200 and the labels match the files.

The rest of the entry verifies. In src/chains/stellar/keys.ts the control key is a random ed25519 key whose public half is the G… address and the account's weight-1 master key. In datamap.ts the seed lives DEK-encrypted under cv:ct/<i>, and cv:wp is a passkey DEK-wrap, so "passkeys enroll devices; they do not sign" is right. StellarRelayer only fee-bumps and sponsors reserves.

Two precision items are left, both on security sentences. Copilot raised both and I confirmed them in your source.

1. "never leaves the device" holds in the browser only. src/stellar.ts exports LocalDeviceUnwrapKey, and its export() returns the raw P-256 scalar for Node and React Native. Your own file comment says the browser implementation "never exposes the scalar". Could you scope the claim: non-extractable in the browser, secure-storage bytes on Node and React Native?

2. "does not sign" needs a subject. approveThisDeviceWithSocialWrap() opens the control seed, and approveThisDevice() signs the MANAGE_DATA write with it. The flow does sign; the enclave does not. Naming the enclave there closes it.

Two things are a maintainer's call, not mine.

• Mainnet evidence. Your docs list Stellar as Available on stellar-testnet and stellar-mainnet, and the 0.1.9 hardening caveat is gone from the README as of the 0.1.10 commit. I could not confirm production-live mainnet use from public sources. constants.ts carries mainnet endpoints only, which the bar excludes; the relayer's mainnet fee payer sits behind an app-id gated endpoint; and the README's only on-chain proofs are Starknet Sepolia. One correction to the PR body: that old caveat's bullet opened "This is the classic G… implementation, not the removed Soroban C… prototype", so it read as applying to the classic path.
• The listing itself. Your profile lists you as founder of Cavos, so this decision belongs to a maintainer.

@kaankacar over to you. I opened a tracking issue.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[kaankacar]

🤖 Automated message from Kaan's Automated Triage Bot.

Thanks for the fast turn again. The enclave sentence is settled. Naming the enclave as the subject is exactly right, because approveThisDevice() does sign the MANAGE_DATA write with the control key.

The device-key sentence is closer, but the new wording joins two different runtimes. Copilot flagged this, and I confirmed all three paths in your source:

• Browser — WebCryptoDeviceUnwrapKey generates a non-extractable ECDH key. Correct as written.
• React Native — @cavos/kit/react-native injects NativeDeviceUnwrapKey with minimumKeySecurity: "os-protected". The scalar never enters JS. That is stronger than "secure-storage bytes".
• Node — there is no default. loadDefaultWebDeviceKey throws "this runtime requires createStellarDeviceKey". The caller passes LocalDeviceUnwrapKey, whose export() returns the raw scalar to persist.

So the line understates React Native and overstates Node. One option:

non-extractable in the browser and on React Native (OS keystore); on Node you supply the key and persist the raw scalar yourself

Everything else still verifies. Both llms links return 200 and the labels match the files.

Two things stay with a maintainer. The mainnet evidence is still open: I looked again today, and your docs list Stellar as Available on stellar-testnet and stellar-mainnet, but I found no production notes and no published mainnet address. The listing itself is also his call, since you founded Cavos.

@kaankacar holds the tracking issue, so I am not merging this one either way.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[adrianvrj]

@kaankacar If you want to try the Stellar mainnet path yourself, I can switch to mainnet the Stellar implementation on at https://demo.cavos.xyz so you can exercise it there.

[kaankacar]

🤖 Automated message from Kaan's Automated Triage Bot.

Thanks for the quick turn. The runtime split reads correctly now, so both technical items are closed.

I checked the new sentence against your source again:

• Browser: WebCryptoDeviceUnwrapKey generates the ECDH key with extractable: false and unwraps with deriveBits.
• React Native: CavosNative.ts wires createStellarDeviceKey to NativeDeviceUnwrapKey, default minimumKeySecurity: "os-protected". The scalar stays in the native module.
• Node: loadDefaultWebDeviceKey throws, so the caller supplies LocalDeviceUnwrapKey, and export() returns the raw scalar for the caller to persist.

Nothing else changed in this push. All six links return 200, and Copilot's review at this head found nothing.

Two things stay with a maintainer. The mainnet evidence is still open: your docs list Stellar on stellar-testnet and stellar-mainnet, but I found no production notes and no published mainnet address, so I cannot check on-chain. The listing itself is @kaankacar's call, since you founded Cavos.

The tracking issue is still open, so I am not merging this. Nothing more is needed from you for now.