[adrianvrj]

Stellar mainnet proof, @cavos/kit 0.5.3: account, create tx sponsored by the Cavos relayer, USDC trustline tx.

Adds Cavos to skills/standards/ecosystem.md under Smart Account & Authentication. This is the listing closed on #112 and #121 for lack of public mainnet evidence. The Community Built skill landed in #183.

Changes from #121, against the 0.5.3 source:

• Key model rewritten for 0.5.x: one Ed25519 spend key, HKDF of a per-user MasterDEK (cavos-ed25519-stellar-v1). The cv:ct control-seed wording from Add Cavos under Smart Account & Authentication #121 no longer applies.
• Key storage scoped per runtime, as the review on Add Cavos under Smart Account & Authentication #121 settled: browser non-extractable WebCrypto (vault iframe by default), React Native OS keystore, Node caller-supplied.
• The enclave is named as the subject: it re-encrypts the sealed MasterDEK to a new device, does not sign, and is part of the trust model.
• Account creation: create() (new in 0.5.3, Add create() to Stellar wallets (0.5.3) cavos-labs/kit#53) creates the sponsored account without a payment, as raised on Add Cavos to the community skills #183.
• Format matches the sibling entries: one-line description, no Twitter/X or Package fields.

Disclosure: I build Cavos.

[stellar-triage-bot]

🤖 Automated message from the Stellar Triage Bot.

👀 Picked this up — a review will follow shortly.

[stellar-triage-bot]

🤖 Automated message from the Stellar Triage Bot.

Thanks for coming back with this, @adrianvrj, and for the clear disclosure. The entry is tight and matches its neighbours, and create() from #183 makes the sponsorship bullet true.

What I checked against @cavos/kit 0.5.3 (npm latest, gitHead d8d8d73):

• The HKDF info string cavos-ed25519-stellar-v1 is in src/secret/derive.ts.
• Soroban auth entries are signed with authorizeEntry. The relayer only sponsors and pays fees. On chain, the example account has one signer, its own key.
• Every link resolves. cavos.xyz and the docs page send our runner a Cloudflare challenge, but llms.txt returns 200.
• The account, create tx and USDC trustline tx in the PR body match Horizon.

One item for you: the React Native and Node part of the key-storage line.

1. For Stellar, Cavos.connect passes deviceKey but no factor (src/Cavos.ts:305-329). Solana and Starknet pass factor.
2. CavosStellar does not use deviceKey (_deviceKey, CavosStellar.ts:166). The native path falls back to WebCryptoDeviceUnwrapKey (nativeAccount.ts:73-79).
3. The React Native provider connects without vault, socialRecovery or passkey (react-native/CavosProvider.tsx:109-124). So Stellar takes the older random-key path, not the MasterDEK path.

So I cannot confirm "the OS keystore on React Native" or "caller-supplied on Node" for Stellar. Could you fix the kit, or scope the line to the browser? Your skill (SKILL.md:58) and docs have the same sentence.

A small point: the vault is the default only in the React provider when appId is set. In core Cavos.connect it is opt-in.

Two decisions belong to a maintainer:

• Mainnet bar. The docs list Stellar as Available on mainnet with no caveat. But all the on-chain evidence is from today. The sponsor account GDJZ…Q6UE was created at 14:36 UTC with 4 XLM, one minute before the example account, and has sponsored only that account.
• The listing. You build Cavos, so the listing is a maintainer's call.

@kaankacar over to you. I opened a tracking issue and I am not merging this.

[adrianvrj]

Thanks. Scoped to the browser rather than claiming React Native or Node:

• Entry: the key is a non-extractable WebCrypto key in the browser, inside the Cavos vault iframe by default in the React provider with an appId. Stellar on React Native and Node is not on this path yet. The vault default wording follows your note (opt-in in core Cavos.connect).
• The Community Built card from Add Cavos to the community skills #183 now says "web app".
• Skill updated the same way (Scope the Stellar skill to the browser; mark React Native WIP cavos-labs/kit#54): https://raw.githubusercontent.com/cavos-labs/kit/main/skills/cavos-stellar/SKILL.md
• Docs updated (docs: React Native is WIP; Stellar MasterDEK path is browser-only cavos-labs/cavos#381): React Native is marked work in progress, and the Stellar page says the MasterDEK path is the browser path.

Making Stellar use the device key on React Native is tracked as kit work, not claimed here.

[stellar-triage-bot]

🤖 Automated message from the Stellar Triage Bot.

Thanks, @adrianvrj. That was a quick and careful fix, and scoping to the browser is the honest call.

I checked the new head against @cavos/kit 0.5.3 (gitHead d8d8d73):

• The browser MasterDEK path imports the key with WebCryptoControlKey.importFromSeed, as a non-extractable key (nativeConnect.ts, WebCryptoControlKey.ts).
• The React provider turns the vault on when appId is set (vaultSetting in react/CavosProvider.tsx). Core Cavos.connect turns it on only when you pass vault.
• The card now says "web app". The skill (Scope the Stellar skill to the browser; mark React Native WIP cavos-labs/kit#54) and the docs (docs: React Native is WIP; Stellar MasterDEK path is browser-only cavos-labs/cavos#381) say the same. The skill URL returns 200.
• site-ci is green at this head.

The open item from my last comment is resolved. I have no more technical requests.

The hold stays open. The mainnet bar and the listing are still decisions for @kaankacar, so I am not merging this.