Ecosystem metrics
- New Repos
- 15
- New
- Commits
- 616
- down 5.8%
- Releases
- 4
- up 33.3%
- Contributors
- 47
- down 14.5%
- Merges
- 25
- up 127.3%
Activity Overview
Commits and releases over time
- Commits
- Releases
- Authors
Repository Explorer
No repositories match that filter.
7547 commits in all time
Jun 30, 2026 01:32 – Sep 28, 2026 01:32 UTC
fix: address code review findings on ARC-56 summary PR
Multiple review passes on #172 found real issues: - Arc56RequestSummary.vue used a plain falsy check on an app-creation call's appIndex (0), silently dropping such transactions from the aggregated summary entirely - fixed to check `=== undefined`. - Arc56RequestSummary.vue collapsed "not looked up" (no approvalHash) and "looked up, no publisher" into the same `[]`, showing a false "no known publisher" warning for calls that were never eligible for a hash lookup (e.g. trust "not-abi") - unlike Arc56CallDetails.vue's deliberate null/[] distinction. Both now share that distinction via the new Arc56OwnerLinks.vue component. - Extracted the trust->severity/copy switch statements (duplicated verbatim between Arc56CallDetails.vue and Arc56RequestSummary.vue) into arc56TrustSeverity/TitleKey/DescKey in decode.ts, so a future Arc56TrustLevel value can't update one view's rendering while silently leaving the other on an incomplete switch. - Extracted the 3x-duplicated GitHub-owner-links markup into Arc56OwnerLinks.vue. - isSingleAppCall was a plain function re-invoked on every render; changed to a computed(). - Restored the app-call guard before dispatching to algod in Arc56CallDetails.vue (was reordered during the previous refactor, currently unreachable given both call sites gate on type=='appl', but latent otherwise). - Added a generation-token guard against stale runDecode() results overwriting fresher ones in both components, and keyed Arc56CallDetails.vue's watch on txID instead of object identity (ConnectRequestsTable/SignAll rebuild their transaction arrays on every store update even when nothing actually changed). - Added an in-memory cache to algod/getApplicationPrograms, keyed by endpoint+appIndex - the summary and detail views (and TransactionGroupSimulation) can all request the same app's programs for the same request, previously each a fresh algod round-trip. - Wired Arc56RequestSummary into SignAll.vue too (raw/offline group signing), not just ConnectRequestsTable - the exact case where a spoofed/unverified app call matters most was previously uncovered. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
718f0a26
feat/arc56-registry-summary
6/235 ++ 178 --
feat: show ARC-56 registry summary and GitHub publisher warnings
Adds an application-call summary above the transaction table in WalletConnect/Liquid Auth requests, so a user relying on "Sign all" doesn't have to expand every app-call transaction to check its ARC-56 registry status: - A request whose only transaction is an app call shows a full summary (trust level, contract name, method, and every GitHub owner/repo known to have published matching source) right above the table. - A request with several app calls (alongside other transactions, or several app calls in one request) shows a compact per-app list with the same trust badge and publisher info, so warnings are visible without crawling through each transaction's expanded detail row. Publisher info comes from the new approval-programs/clear-programs/ <hash>.owners.json files exposed by the companion ARC56Registry change (scholtz/ARC56Registry#1): every GitHub owner/repo whose indexed spec compiles to the app's program hash, not just the largest matching spec - since a legitimate contract can be forked/vendored across several repos, but an app with *no* known publisher at all is exactly the case a scam is most likely to hide in. - src/scripts/arc56/registry.ts: fetchArc56OwnersByProgramHash(), new Arc56Owner/Arc56OwnersEntry types. - src/scripts/arc56/decode.ts: extracted encodeAddressSafe()/ buildAppCallInfo() out of Arc56CallDetails.vue so the new summary component and the existing per-transaction detail view share the same address-encoding and preceding-group-txn logic instead of duplicating it. - src/components/Arc56RequestSummary.vue: the new summary component. - src/components/Arc56CallDetails.vue: also shows publisher info in the existing per-transaction detail view. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
a2212e6e
feat/arc56-registry-summary
17/436 ++ 46 --
ARC-14 auth: show account name in prompt, auto-send after signing (#171)
* feat: show account name in ARC-14 auth prompt, auto-send after signing
Closes #170
- Authenticate button/label now reads "Authenticate to {realm} with
{account}" when the signing account has a name, instead of just
"Authenticate to {realm}".
- ARC-14 auth requests are never broadcast to the chain (they only
produce a login signature), so there's no decision left for the
user after signing - clicking Authenticate now signs and relays the
result to the dApp in the same step, instead of waiting for a
separate "Send back to DApp" click.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix: guard ARC-14 auto-send against mixed/partial requests
Code review on #171 found that the ARC14 auto-send comment's
assumption ("a request containing an ARC14 auth txn is always exactly
that single transaction") is not actually enforced anywhere - a dApp
can legally bundle an ungrouped auth transaction alongside ordinary
payment/asset transactions in the same request. Signing the auth
transaction first (e.g. via "Sign all") would previously trigger
sendResult while the other transactions were still unsigned, sending
the dApp a response with null placeholders and deleting the request
before the remaining transactions could be signed.
- clickSign now takes the parent RequestItem explicitly instead of
re-deriving it by searching all pending requests for a matching
txID (which could also resolve to the wrong request if two pending
requests happened to contain byte-identical transactions).
- Auto-accept only fires once the whole request consists of nothing
but ARC14 auth transactions and all of them are signed
(isArc14OnlyRequest + allTransactionsSigned).
- clickAccept now guards against being dispatched twice for the same
request id, since WalletConnect/Liquid Auth's sendResult is a
one-shot response and a second call would throw or no-op
inconsistently.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix: account for multisig threshold in ARC-14 auto-send gate
Further code review on #171: allTransactionsSigned() was checking
plain membership in signer.signed, but a multisig transaction is
added there as soon as the first of N required co-signatures is
present (see signer.ts's setSigned), not once the threshold is met.
For an ARC14-only request mixing a multisig-sender auth txn with a
regular one, this could auto-accept and relay an under-signed
multisig transaction to the dApp as soon as the other txn was signed.
Reuses the existing toBeSigned() helper, which already decodes msig
subsig counts against the threshold, instead of re-deriving a weaker
check.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix: guard reject against racing an in-flight ARC-14 auto-accept
Further code review on #171: the ARC14 auto-accept path (sendResult)
can be in flight (awaiting a network round-trip to the dApp) while the
Reject button remains clickable, since it was only gated on
wallet.isOpen. Clicking Reject at that point would dispatch a second,
conflicting terminal response (cancelRequest) for the same request id
to the same dApp.
Renamed the existing accept-vs-accept re-entrancy guard to cover
reject-vs-accept too, so whichever of sendResult/cancelRequest starts
first for a given request id wins and the other silently no-ops,
matching the existing no-toast convention for the accept-side guard.
Also added a clarifying comment on arc14AuthenticateLabel's account-name
fallback: an account matched by address but with a blank name
intentionally falls back to the plain realm-only label (showing
"with " followed by nothing would look broken), so this isn't a bug
to fix even though a reviewer flagged the falsy check.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix: surface an error toast when rejecting a request fails
clickReject was restructured with try/finally to add the
respondingRequestIds guard but had no catch, unlike clickAccept,
so a failed cancelRequest dispatch (e.g. a WalletConnect transport
error) surfaced no feedback - the user would believe their reject
went through. Mirrors clickAccept's existing error-toast handling.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: Ludovit Scholtz <ludovit.scholtz@aaaauto.cz>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
4f18a9a0
master
12/108 ++ 19 --
fix: surface an error toast when rejecting a request fails
clickReject was restructured with try/finally to add the respondingRequestIds guard but had no catch, unlike clickAccept, so a failed cancelRequest dispatch (e.g. a WalletConnect transport error) surfaced no feedback - the user would believe their reject went through. Mirrors clickAccept's existing error-toast handling. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
80b9fd0d
pull/171/head
1/7 ++ 0 --
fix: guard reject against racing an in-flight ARC-14 auto-accept
Further code review on #171: the ARC14 auto-accept path (sendResult) can be in flight (awaiting a network round-trip to the dApp) while the Reject button remains clickable, since it was only gated on wallet.isOpen. Clicking Reject at that point would dispatch a second, conflicting terminal response (cancelRequest) for the same request id to the same dApp. Renamed the existing accept-vs-accept re-entrancy guard to cover reject-vs-accept too, so whichever of sendResult/cancelRequest starts first for a given request id wins and the other silently no-ops, matching the existing no-toast convention for the accept-side guard. Also added a clarifying comment on arc14AuthenticateLabel's account-name fallback: an account matched by address but with a blank name intentionally falls back to the plain realm-only label (showing "with " followed by nothing would look broken), so this isn't a bug to fix even though a reviewer flagged the falsy check. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
15dd738a
feat/arc14-account-name-autosend
1/30 ++ 16 --
fix: account for multisig threshold in ARC-14 auto-send gate
Further code review on #171: allTransactionsSigned() was checking plain membership in signer.signed, but a multisig transaction is added there as soon as the first of N required co-signatures is present (see signer.ts's setSigned), not once the threshold is met. For an ARC14-only request mixing a multisig-sender auth txn with a regular one, this could auto-accept and relay an under-signed multisig transaction to the dApp as soon as the other txn was signed. Reuses the existing toBeSigned() helper, which already decodes msig subsig counts against the threshold, instead of re-deriving a weaker check. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
15819c34
feat/arc14-account-name-autosend
1/6 ++ 5 --