Add Cogladius to community skills

[furkanyesildag]

Adds Cogladius to ECOSYSTEM_CARDS.

Cogladius is a permissionless task marketplace on Stellar. Humans post tasks with an XLM reward locked in a non-custodial Soroban escrow; autonomous AI agents compete to solve them; a three-judge AI panel scores submissions and the escrow contract releases the XLM reward to the winner on an on-chain, ed25519-verified verdict.

The SKILL.md teaches an AI agent to register (one permissionless API call), poll open tasks, solve, and submit to earn XLM.

• Skill: https://github.com/furkanyesildag/cogladius/blob/main/SKILL.md
• Product (live on mainnet): https://cogladius.xyz
• Repo: https://github.com/furkanyesildag/cogladius

[Copilot]

Pull request overview

Adds Cogladius to the community skills catalog.

Changes:

• Adds a card describing Cogladius’s task marketplace workflow.
• Links to its externally hosted SKILL.md.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[furkanyesildag]

Thanks for the review! I've added valid Agent Skill YAML frontmatter (name and description, plus user-invocable/argument-hint) to the upstream SKILL.md, so it's now a self-contained, installable skill:

https://github.com/furkanyesildag/cogladius/blob/main/SKILL.md

Let me know if anything else is needed 🙏

[kaankacar]

Thanks for this — the settlement design is a genuinely nice pattern, and I checked that env.crypto().ed25519_verify matches what the docs describe, so the on-chain verdict part reads solid to me.

Before it goes on the catalog I want to make sure I'm reading a few things correctly:

Which asset does the reward actually settle in? The card and SKILL.md say XLM ("Payout: native XLM on Stellar mainnet"), but the escrow looks USDC-shaped from where I'm standing — config.usdc_sac, the token::TokenClient::new(&env, &config.usdc_sac).transfer(...) calls in post_task / release_to_winner / refund, and the README's mainnet proof txs describing "0.2 USDC locked" and "USDC paid to the winner". Is XLM a planned change that the skill is written ahead of, or am I misreading which path mainnet uses today?

The task reward field. SKILL.md documents each task as carrying reward (in XLM), but in app/app/api/agents/tasks/route.ts the response looks like rewardSol: t.rewardUsdc ?? .... If an agent reads reward, does it get a value? Wondering whether the snippet is from an earlier response shape.

Trustline. If the payout is USDC over the SAC, does the agent's G... address need a USDC trustline before it can receive anything? If so, would it be worth a line in the skill — right now an agent following it would just expect native XLM to show up.

Why the secret key? agents/cogladius-agent.js asks for STELLAR_AGENT_SECRET (an S...), but as far as I can trace it only ever calls kp.publicKey() to register — nothing seems to get signed locally. Is the secret needed for something I'm missing, or could the reference agent take just the pubkey? I ask because agents following this will end up holding a live mainnet secret in an env var, and in the no-secret branch the generated one gets printed to stdout.

Happy to merge once the asset story lines up across the card, the skill, and the contract.

[furkanyesildag]

Thanks for the careful read — and sorry for the runaround. You were reading the repo correctly; the repo was lying. Two of your four points were real bugs, and the other two came from documentation I'd left stale. All four are now fixed.

1. Which asset — XLM is correct, the README was stale

The skill and the card are right: mainnet settles in native XLM today. What you were reading was a pre-migration README.

The escrow is SEP-41 asset-agnostic — it moves whatever SAC address __constructor was given. The first deployment passed the Circle USDC SAC. On 2026-07-11 I redeployed against the native XLM SAC, specifically so that agents wouldn't need a trustline (more on that in #3):

	Live	Retired
Escrow	CAC5EDF76M5LY43BNHT47Y5NZRHO4ZRH7SRFPNHATGNKN2DI3SNK75PL	CBZ54RRGG4S5RZXW2BC26SIDFYVTB5XQDV3AYU42WQYBRNNUWZBACYTO
Reward SAC	CAS3J7GY…OWMA (native XLM)	CCW67TSZ…MI75 (USDC)

The config.usdc_sac field and the token::TokenClient::new(&env, &config.usdc_sac).transfer(...) calls you traced are real — but usdc_sac is a legacy field name, not the asset. I kept the name because renaming it changes the contract spec and would force a redeploy of a live contract for a cosmetic gain. It's now documented as such in the contract source, and the same note covers the NEXT_PUBLIC_USDC_* env vars and the rewardUsdc identifier. Anywhere the name says USDC, the value is XLM.

What I fixed: the README was entirely pre-migration — wrong contract ID, wrong SAC, USDC throughout. Swept. app/.env.local.example was worse: it pointed at the retired contract, so anyone copying it would have wired themselves to a dead deployment. Also fixed, along with the mainnet fallbacks in app/lib/constants.ts.

One thing I want to flag rather than paper over: the three proof transactions in the README are genuine mainnet transactions, but they ran against the USDC deployment. Same contract code, byte-for-byte — only the SAC address in the constructor differs — but they are not XLM proofs. I've labeled them honestly instead of quietly relabeling them "XLM". If you'd like a fresh post → release → refund cycle on CAC5EDF7… before this goes on the catalog, say the word and I'll run one and post the hashes.

2. The reward field — you found a real bug

Correct, and thank you. An agent reading reward got undefined. rewardSol is a leftover from the Solana original that survived two asset migrations; SKILL.md documented the field the response should have had.

The endpoint now returns reward (the documented name), plus rewardXlm as an explicit alias and rewardAsset: "XLM". rewardSol stays for one release so existing agents don't break, marked deprecated in both the code and the skill.

3. Trustline — not needed, and that's exactly why XLM

This one resolves itself once #1 is straight: the payout is the native asset, so no trustline is involved. Avoiding the trustline onboarding step is precisely why I switched off USDC — an agent shouldn't have to sign a changeTrust before it can earn.

There is a real precondition, though, and you were right that the skill was silent on it. Native or not, the receiving account has to already exist on-chain (funded to at least the 1 XLM base reserve). A freshly generated, never-funded address cannot receive the payout. That's now stated in SKILL.md.

While checking this I found the migration had left two broken paths behind: fetchUsdcBalance was still looking for a non-native balance line with code XLM and a USDC issuer — so the dashboard showed 0 for every connected wallet — and a dead addUsdcTrustline helper that would have thrown on new Asset("XLM", ""). Fixed and removed respectively.

4. The secret key — you're right, it never needed one

Nothing is signed locally. Registration is authenticated by the API key it returns, and payouts are pushed to the address by the contract; kp.publicKey() was genuinely the only use. Asking for an S... bought the agent no capability and created exactly the exposure you describe — worse in the no-secret branch, which generated a keypair and printed the secret to stdout, so a copy-pasted quickstart could have earned real mainnet XLM into a key living only in a terminal scrollback.

The reference agent now takes STELLAR_AGENT_PUBKEY (public key only). STELLAR_AGENT_SECRET is still accepted for compatibility but only its public key is derived, with a deprecation warning. The generate-and-print path is gone: with no address configured the agent refuses to start and tells you to generate one you control, rather than inventing an address on your behalf.

One more thing came out of testing that fix. Both the agent and POST /api/agents/register validated addresses with a bare ^G[A-Z2-7]{55}$ shape regex, which accepts a typo'd address that isn't a valid strkey — an agent could register an address it can never be paid at. Both sides now validate the full strkey checksum (StrKey.isValidEd25519PublicKey / Keypair.fromPublicKey).

---

Changed: README.md, SKILL.md, agents/cogladius-agent.js, app/.env.local.example, app/lib/constants.ts, app/lib/stellar.ts, app/lib/sorobanEscrow.ts, app/app/api/agents/tasks/route.ts, app/app/api/agents/register/route.ts, contracts/cogladius-escrow/src/lib.rs.

Contract suite is green (16 tests, including bad-signature revert and verdict-key rotation) and the app typechecks clean. Happy to run the fresh XLM lifecycle on the live contract if you want that in the README before merge.

---

@Copilot — on the frontmatter: SKILL.md does carry Agent Skill YAML frontmatter (name: cogladius, description, plus user-invocable and argument-hint) and has since b1325cf, which landed before this catalog PR was opened. The linked file on main starts with the --- block, not the H1 — I think the review looked at an earlier state of the file. Worth a re-check against current main.