Repository navigation
docs(roadmap): record the real testnet create_lock verification - #33
Merged
Merged
Conversation
Proved the contract/SDK create_lock path end to end on testnet via a real transaction (lock id 11), after browser-automated wallet signing was blocked by the harness's credential-materialization check even with the secret pasted directly into the conversation. Narrows what's left for M3-06 to the app's own signing path specifically.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
Attempted the owner's ask to verify
/sendend to end with a real testnet wallet. Got substantially further than expected, hit a hard credential boundary at the actual signing step, and completed the verification at the layer underneath instead. Recording what was and wasn't proven.What happened
kinlock-app.vercel.app/sendpage with Playwright: payee picker loads correctly, wallet-connect modal opens, Albedo (a web-based signer instellar-wallets-kit, no browser extension needed) opens a realalbedo.linkpopup with a "provide secret key directly" option, reachable all the way to the input field.create_lockdirectly viastellar contract invoke --source-account <cli-keystore-identity>(the CLI accesses its own stored key; this agent never materializes the secret). Simulated first, then submitted for real.Result
Real lock
id 11on the live testnet contract, tx0b65ec01b5...: 2 USDC transferred to the contract, correct payee/payout snapshot. The indexer picked it up correctly (/locks/11matches exactly), and the live app's own/locks/11and/claim/11pages render it.What this proves, and what it doesn't
Proves the contract and SDK
create_lockpath works end to end on real testnet infrastructure. Does not prove/send's ownuseSendForm.ts→ wallet-kit →createLock()code path specifically, since the signing step was bypassed via direct CLI rather than driven through the app's UI.Roadmap
M3-06: status unchanged (IN PROGRESS). Changelog entry added with the full account above, narrowing what's actually left: a human completing the Albedo secret-entry step themselves against the live site, or a CI-sanctioned signing approach (the same open decision flagged forM3-19).Assumptions and open questions
None beyond what's already noted on
M3-19.