Ecosystem metrics
- New Repos
- 22
- down 98.8%
- Commits
- 862
- up 14.2%
- Releases
- 8
- down 20.0%
- Contributors
- 53
- up 0.0%
- Merges
- 41
- up 86.4%
Activity Overview
Commits and releases over time
- Commits
- Releases
- Authors
Repository Explorer
No repositories match that filter.
6615 commits in all time
May 27, 2026 15:44 – Aug 25, 2026 15:44 UTC
feat: registry funding panel sizing worst-case MBR for both registries
Both registries fund their children rather than themselves, and neither a vote nor a delegation carries a payment from the caller — so an underfunded registry does not fail loudly, it just starts rejecting them. This panel on /manage is the early warning: what each registry must be able to supply, against what it holds, with a turnout slider on the voting term. The arithmetic lives in lib/mbrEstimate.ts as pure functions over already-fetched data, so scripts/check-mbr-estimate.ts can pin the composition the frontend has no test runner for (chunk rounding, the delegation terms, per-instance folding). The box-size formula itself moves to ggov-sdk's voteRecordMbr and is pinned against the compiled ARC-56 specs in boxNames.spec.ts. Two things the estimate gets right that a simpler reading would not: - A period counts when it is *ready* and not yet ended. A ready period whose window is still ahead has to be funded before it opens; an unready one is a draft whose ballot, committee and window can all still change. - Delegation is charged against two disjoint populations. setVotingAccount admits a delegator either registry knows — ensureDelegatorRegistered falls back to the frac registry, because an AQ holder may have no gGov committee membership — and the gGov registry pays the same box pair either way. So the panel splits gGov accounts from frac-only ones over address *sets*: anyone on both registries is counted once, and a frac-only delegator is no longer subtracted from the gGov count.
bf65a4a2
feat/registry-mbr-estimate
20/1,596 ++ 29 --
Merge 7f3217327ec5567c036eed1a25788a7050b86881 into 35e2c3bd36d7b1bd4ce5b12ef2f1b86c73cadf3b
a980d3d4
pull/35/merge
3/187 ++ 4 --
Merge pull request #904 from sambitsargam/dependabot/npm_and_yarn/algosdk-tw-3.7.0
build(deps): update algosdk requirement from ^3.6.0 to ^3.7.0
a23fb68e
main
1/1 ++ 1 --
Merge pull request #905 from sambitsargam/dependabot/npm_and_yarn/eslint-10.9.0
build(deps-dev): bump eslint from 10.9.1 to 10.9.0
74a52a29
main
1/1 ++ 1 --
docs: correct the upload fee and page-ceiling comments
The SDK constants' fee docstring still described coverAppCallInnerTransactionFees; the upload actually probes with simulate() and derives the fee from groupUsage. Both registries claimed the three-page read covers the 12288 bytes a v13 approval program can reach. The upload carries 3 x 4094 = 12282 (ARC-4 length prefix), and v13's 7 extra pages allow 16384 — so it is short of a program that fills them.
43c63630
feat/avm13-computed-pages
4/18 ++ 12 --
feat: registries open their boxes to foreign reads at create
AVM v13 relaxes box isolation: an app can opt its boxes into reads by any other app. Both registries now do that in a new createApplication, which runs app_params_set(appForeignBoxReads, true). Verified on localnet that the opcode is permitted during the creating call itself, so no separate post-create step is needed - the v13 notes describe enabling access as update-then-run, but that is for apps already deployed. Reads only; writes stay exclusive to the owning app. app_params_set is run by an app on itself, so a contract that is not updatable can never opt in later, which is what preserves intentional immutability. The create is a real ABI method rather than a bare one. It lands in the ARC-56 and the generated clients, it can take arguments later without changing the create shape a second time, and it matches the house style - FracDelegationInstance already has an ABI createApplication invoked by selector from the registry factory. Both createRegistry paths switch from create.bare() to the method call; every other caller routes through createRegistry. Two consequences of the create no longer being bare, both found by the suite: - deployRegistryWithoutBytecode in the period e2e spec deploys a registry directly and was still doing a bare create, which is no longer routed and fails with an err on the OnCompletion match. - The ATST unit specs. ATST holds a contract with any create method in `isCreating` and rejects every ABI call with "method can not be called while creating" until a create method runs - but ATST 1.2.0 predates v13 and cannot execute app_params_set, so the real body cannot run in the emulator. The registry test subclass overrides createApplication with a no-op and calls it after construction; the opt-in itself is covered e2e. Follow-up worth taking: with foreign reads on, much of the registries' readonly getter and log-dumping surface (getDelegation, getPeriodSummary, logCommitteePages, getEscrow, ...) exists only because cross-app box reads used to be impossible. Not touched here. Suite green: 539 passed (2 new).
9893837d
feat/avm13-foreign-box-reads
22/6,652 ++ 6,099 --
docs: give the frac SDK's extraProgramPages comment its own numbers
The block was copied verbatim from the ggov SDK and still named GGovRegistry and its ~5.6KB program / 6144-byte exact ceiling. FracDelegationRegistry is ~2.9KB, so exact sizing gives it a 4096-byte ceiling; the argument for the spare page is unchanged, only the figures were wrong. Also narrows the parenthetical to instance apps, which are the only children this registry spawns.
b7f8375e
feat/avm13-computed-pages
1/7 ++ 7 --