Open
Conversation
Contributor
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThis changeset introduces support for a new Governor contract type in the Stellar wizard, enabling token-based governance. It extends existing contract types (Fungible, NonFungible, Stablecoin) with voting capabilities and refactors the upgrade mechanism to use explicit trait implementations. Version dependencies are bumped to OpenZeppelin Stellar Soroban Contracts v0.7.0 and Soroban SDK 25.3.0. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
ozgunozerk
commented
Mar 30, 2026
ozgunozerk
commented
Mar 30, 2026
brozorec
reviewed
Mar 30, 2026
brozorec
approved these changes
Apr 7, 2026
Contributor
Author
|
the code generated for timelock does not match the examples we have, and I'm not sure whether it may even compile. Also after conflict is resolved and tests are passing again, I think we can mark this PR ready for review |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
packages/core/stellar/src/zip-shared.test.ts (1)
202-231:⚠️ Potential issue | 🟠 MajorRemove
stellar-governancefrom the unconditional shared dependencies.
stellar-governanceis now included in every generated Stellar contract vialibDependencies(line 46 in zip-shared.ts), which feeds intoprintContractCargo. This adds the governance crate to all templates regardless of whether they use Governor features, broadening the scope of any release blocker affecting that dependency.If governance is only needed for Governor/votes variants, move it out of
libDependenciesand add it conditionally based on scaffold type instead. Otherwise, all generated contracts—including those that don't use voting or governance—will carry the extra dependency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/stellar/src/zip-shared.test.ts` around lines 202 - 231, The shared dependency list libDependencies currently unconditionally includes "stellar-governance", causing printContractCargo to add it to every contract; remove "stellar-governance" from the libDependencies array and instead add logic in the code path that builds cargo dependencies for a scaffold to include "stellar-governance" only when the scaffold type indicates Governor/votes variants (the code that calls printContractCargo or the function that merges libDependencies into the contract-specific dependencies should detect scaffold type and append stellar-governance conditionally). Update the functions printContractCargo and the scaffold dependency assembly to rely on the revised libDependencies plus this conditional addition so non-governor templates no longer get the governance crate.packages/common/src/ai/schemas/schemas.test.ts (1)
94-96:⚠️ Potential issue | 🟡 MinorMissing
stellarGovernorSchemafrom description presence tests.The
stellarGovernorSchemais correctly imported and used in the type assertion function (line 152), but it's not added to theallSchemasarray. This means the Governor schema fields won't be tested for.describe()presence like the other stellar schemas.🔧 Proposed fix
['stellarFungible', stellarFungibleSchema], + ['stellarGovernor', stellarGovernorSchema], ['stellarStablecoin', stellarStablecoinSchema], ['stellarNonFungible', stellarNonFungibleSchema],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/common/src/ai/schemas/schemas.test.ts` around lines 94 - 96, The tests for schema `.describe()` presence are missing the stellarGovernorSchema entry; add the pair ['stellarGovernor', stellarGovernorSchema] into the allSchemas array alongside the other stellar schemas so the Governor schema fields are included in the describe-presence tests (the type assertion already references stellarGovernorSchema elsewhere). Locate the allSchemas array in the schemas.test.ts file and insert the ['stellarGovernor', stellarGovernorSchema] tuple so the describe presence loop covers it.packages/core/stellar/src/fungible.ts (1)
2-3:⚠️ Potential issue | 🟠 Major
mintablestill disappears whenaccessis omitted.
case falseexits before either mint entrypoint is emitted, somintable: truestill generates a token with no publicmint. The new votes permutations inherit the same bug — the addedfungible votes burnable mintablesnapshot already shows that path missingmint.🔧 Suggested fix
-import { requireAccessControl, setAccessControl } from './set-access-control'; +import { DEFAULT_ACCESS_CONTROL, requireAccessControl, setAccessControl } from './set-access-control'; ... function addMintable( c: ContractBuilder, access: Access, votes: boolean, pausable: boolean, explicitImplementations: boolean, ) { + const effectiveAccess = access === false ? DEFAULT_ACCESS_CONTROL : access; const mintFn = votes ? votesFunctions.mint : functions.mint; const mintWithCallerFn = votes ? votesFunctions.mint_with_caller : functions.mint_with_caller; - switch (access) { - case false: - break; - case 'ownable': { + switch (effectiveAccess) { + case 'ownable': { c.addFreeFunction(mintFn); - requireAccessControl(c, undefined, mintFn, access, undefined, explicitImplementations); + requireAccessControl(c, undefined, mintFn, effectiveAccess, undefined, explicitImplementations); if (pausable) { c.addFunctionTag(mintFn, 'when_not_paused'); } break; } case 'roles': { c.addFreeFunction(mintWithCallerFn); requireAccessControl( c, undefined, mintWithCallerFn, - access, + effectiveAccess, { useMacro: true, caller: 'caller', role: 'minter', }, explicitImplementations, );Also applies to: 161-209
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/stellar/src/fungible.ts` around lines 2 - 3, The mint entrypoint is skipped when access is omitted because the code returns early in the `case false` branch before emitting mint logic; update the control flow so `mintable: true` always emits the mint entrypoint regardless of whether `access` was provided. Concretely, in the function handling fungible token generation (references: the `access` parameter, the `mintable` flag, and the helpers `requireAccessControl` / `setAccessControl`) ensure you compute a canonical access (e.g., default public access or call `setAccessControl`/`requireAccessControl` as needed) and move the mint-emission logic out of the early-return path so that when `mintable` is true you always add the public `mint` entrypoint; apply the same change to the other permutations mentioned (the block covering lines ~161-209).packages/core/stellar/src/add-upgradeable.ts (1)
2-3:⚠️ Potential issue | 🟠 MajorNormalize
accessbefore selecting the upgrade function variant.Line 32 branches on the raw
accessvalue before normalization. Whenaccess === false(default), it selectsfunctions.upgrade(withoperatorparameter), butrequireAccessControlthen normalizesaccessto'ownable'internally (at line 87 of set-access-control.ts), creating a signature mismatch: the function declaration won't match the access guard applied. Other helpers (add-pausable.ts, non-fungible.ts) correctly normalizeaccesstoeffectiveAccessbefore branching.🔧 Suggested direction
+import { DEFAULT_ACCESS_CONTROL, requireAccessControl } from './set-access-control'; -import { requireAccessControl } from './set-access-control'; ... + const effectiveAccess = access === false ? DEFAULT_ACCESS_CONTROL : access; + const upgradeFn: BaseFunction = effectiveAccess === 'ownable' ? functions.upgrade_unused_operator : functions.upgrade; - const upgradeFn: BaseFunction = access === 'ownable' ? functions.upgrade_unused_operator : functions.upgrade; ... requireAccessControl( c, upgradeableTrait, upgradeFn, - access, + effectiveAccess, { useMacro: true, role: 'upgrader', caller: 'operator', }, explicitImplementations, );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/stellar/src/add-upgradeable.ts` around lines 2 - 3, Normalize the incoming access value before choosing the upgrade function variant: call the same normalization used by requireAccessControl (so you get an effectiveAccess) and branch on that normalized value instead of the raw access variable; then select the proper function (e.g., functions.upgrade vs functions.upgradeWithOperator or the variant that expects an operator) based on effectiveAccess so the declared function signature matches the access guard applied (refer to add-upgradeable.ts variable access, functions.upgrade, and requireAccessControl for where to apply this change).
🧹 Nitpick comments (4)
packages/mcp/src/stellar/tools/stablecoin.test.ts (1)
41-47: Please add onevotes: truefixture.Both added assertions only cover the disabled branch, so a regression that ignores
voteswhen enabled would still pass here.Also applies to: 63-69
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/mcp/src/stellar/tools/stablecoin.test.ts` around lines 41 - 47, The tests only exercise the votes:false branch in the stablecoin tests; add a separate fixture where votes: true and assert the enabled-votes behavior so regressions that ignore votes when enabled will fail. Specifically, in the test suite around test('all default', ...) create an additional test case (or modify the existing suite) that supplies params with votes: true (same shape as DeepRequired<z.infer<typeof t.context.schema>>) and add assertions that validate the contract/state changes expected when votes are enabled; do the same for the analogous test near lines 63-69 so both the enabled and disabled branches of votes are covered.packages/mcp/src/stellar/tools/non-fungible.test.ts (1)
42-49: Please add onevotes: truefixture.Both new cases only exercise the default/false branch, so a tool that accidentally drops
voteswhen enabled would still pass this suite.Also applies to: 69-76
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/mcp/src/stellar/tools/non-fungible.test.ts` around lines 42 - 49, Add a new test-case fixture that sets votes: true so the branch where votes is enabled is exercised; specifically, in the test named 'all default' (where the params object is built) add a separate test or modify/create a fixture variant that uses DeepRequired<z.infer<typeof t.context.schema>> params with votes: true (and the same other fields: name, symbol, tokenUri, burnable, enumerable) and assert the expected behaviour, and do the same for the other test around the 69-76 block to ensure the enabled-votes path is covered.packages/core/stellar/src/stablecoin.test.ts (1)
145-159: Consider covering theblocklistbranch in the incompatibility test as well.Line 145 currently asserts only
allowlist; addingblocklistkeeps this guard fully covered.Proposed test extension
test('throws error when votes and limitations are both enabled', t => { - const error = t.throws( - () => - buildStablecoin({ - name: 'MyStablecoin', - symbol: 'MST', - votes: true, - limitations: 'allowlist', - }), - { instanceOf: OptionsError }, - ); - - t.is(error?.messages.votes, 'Votes extension cannot be used with stablecoin limitations'); - t.is(error?.messages.limitations, 'Stablecoin limitations cannot be used with Votes extension'); + for (const limitations of ['allowlist', 'blocklist'] as const) { + const error = t.throws( + () => + buildStablecoin({ + name: 'MyStablecoin', + symbol: 'MST', + votes: true, + limitations, + }), + { instanceOf: OptionsError }, + ); + + t.is(error?.messages.votes, 'Votes extension cannot be used with stablecoin limitations'); + t.is(error?.messages.limitations, 'Stablecoin limitations cannot be used with Votes extension'); + } });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/stellar/src/stablecoin.test.ts` around lines 145 - 159, Update the existing test "throws error when votes and limitations are both enabled" to also assert the incompatibility when limitations is set to 'blocklist': call buildStablecoin with votes: true and limitations: 'blocklist', expect an OptionsError, and assert error.messages.votes equals 'Votes extension cannot be used with stablecoin limitations' and error.messages.limitations equals 'Stablecoin limitations cannot be used with Votes extension' (use the same pattern as the existing allowlist assertions referencing buildStablecoin and OptionsError).packages/core/stellar/src/contract.ts (1)
255-257: Defensively copy top-level declaration lines on insert.Line 256 stores the caller-owned array by reference, so later mutations can unintentionally rewrite contract output.
♻️ Suggested patch
addTopLevelDeclaration(lines: string[]): void { - this.topLevelDeclarations.push(lines); + this.topLevelDeclarations.push([...lines]); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/stellar/src/contract.ts` around lines 255 - 257, addTopLevelDeclaration currently stores the caller-owned array reference into this.topLevelDeclarations, allowing external mutation to alter contract output; change the implementation of addTopLevelDeclaration to push a defensive copy of the incoming lines (e.g., clone with slice() or spread) so this.topLevelDeclarations receives an owned array copy and subsequent external changes to the original lines array won't affect stored declarations.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/common/src/ai/schemas/stellar.ts`:
- Around line 27-36: stellarStablecoinSchema currently inherits the votes
description from stellarFungibleSchema via spreading, causing a mismatch; locate
the stellarStablecoinSchema definition and explicitly override the votes field
(e.g., add votes:
z.boolean().optional().describe(stellarStablecoinDescriptions.votes)) in the
stellarStablecoinSchema object after spreading stellarFungibleSchema so the
stablecoin schema uses stellarStablecoinDescriptions.votes instead of
stellarFungibleDescriptions.votes.
In `@packages/core/stellar/src/governor.ts`:
- Around line 247-263: The cancel implementation only updates governor storage
but fails to cancel the corresponding timelock operation; update cancel (the
cancel entry in governor.ts) to also call the timelock's cancel_op for the
operation scheduled in queue(): compute or retrieve the same operation ID used
by queue() (using storage::hash_proposal or the persisted value that schedule_op
returned) and invoke the timelock's cancel_op before or after storage::cancel(e,
...) so the external timelock state is reset; ensure you use the same parameters
(targets, functions, args, description_hash) that queue/schedule_op used and
preserve the existing proposer/operator checks (proposer,
operator.require_auth()) around the added cancel_op call.
In `@packages/core/stellar/src/non-fungible.test.ts.md`:
- Around line 782-784: The generated upgrade function signature currently uses
an unused parameter named operator; update the signature in the upgrade
implementation (function upgrade) to use a consistently ignored parameter name
`_operator` and leave the body calling upgradeable::upgrade(e, &new_wasm_hash)
unchanged so the compiler won’t warn about an unused parameter across
governor.test.ts.md, non-fungible.test.ts.md, and fungible.test.ts.md.
In `@packages/core/stellar/src/utils/compile-test.ts`:
- Around line 71-75: The current try/catch around copyFile(upstreamLockPath,
path.join(workspaceDir, 'Cargo.lock')) swallows all errors; change it to only
ignore a missing source (errno ENOENT) and rethrow or propagate any other error
so bad paths/perm issues aren't hidden. Specifically, wrap the await copyFile
call in a try block, inspect the caught error in the catch for error.code ===
'ENOENT' and silently ignore only that case, otherwise rethrow the error (or
throw a new error with context referencing upstreamLockPath and workspaceDir) so
callers of compile-test.ts can detect unexpected failures.
- Around line 148-154: The presence check using `'explicitImplementations' in
optsWithExplicit` is wrong because tests omit the optional field; instead merge
defaults first and check the merged options or check the contract kind support
explicitly. Replace the supportsExplicitImplementations assignment so it uses
the defaults-aware options (e.g. const mergedOpts =
withCommonContractDefaults(opts as GenericOptions); const
supportsExplicitImplementations = 'explicitImplementations' in mergedOpts) or
test mergedOpts.contractKind against the known supported kinds, then keep the
rest of the guard (shouldBeExcludedOrHasAlreadyRun using
testOptions.excludeExplicitTraitTest, optsWithExplicit.explicitImplementations)
the same.
In `@packages/ui/src/stellar/GovernorControls.svelte`:
- Around line 87-90: Update the tooltip text in GovernorControls.svelte so it is
authority-agnostic: change the HelpTooltip tied to the opts.upgradeable checkbox
to a neutral description (e.g., "Allows the contract to be upgraded by the
configured authority (owner or accounts with the upgrader role)." or similar) so
it no longer assumes owner-only permissions; locate the HelpTooltip adjacent to
the input bound to opts.upgradeable and replace the owner-specific copy.
In `@packages/ui/src/stellar/NonFungibleControls.svelte`:
- Around line 74-80: When the Votes checkbox (opts.votes) is toggled on in
NonFungibleControls.svelte, immediately clear or disable the conflicting flags
(opts.enumerable and opts.consecutive) instead of relying on later validation;
implement an on:change handler for the Votes input that, when checked, sets
opts.enumerable = false and opts.consecutive = false (and when unchecked, leaves
them unchanged), and update the Enumerable and Consecutive controls to reflect
this by disabling their inputs (disabled={opts.votes}) and visually indicating
they are unavailable when opts.votes is true so users cannot select the invalid
combinations.
---
Outside diff comments:
In `@packages/common/src/ai/schemas/schemas.test.ts`:
- Around line 94-96: The tests for schema `.describe()` presence are missing the
stellarGovernorSchema entry; add the pair ['stellarGovernor',
stellarGovernorSchema] into the allSchemas array alongside the other stellar
schemas so the Governor schema fields are included in the describe-presence
tests (the type assertion already references stellarGovernorSchema elsewhere).
Locate the allSchemas array in the schemas.test.ts file and insert the
['stellarGovernor', stellarGovernorSchema] tuple so the describe presence loop
covers it.
In `@packages/core/stellar/src/add-upgradeable.ts`:
- Around line 2-3: Normalize the incoming access value before choosing the
upgrade function variant: call the same normalization used by
requireAccessControl (so you get an effectiveAccess) and branch on that
normalized value instead of the raw access variable; then select the proper
function (e.g., functions.upgrade vs functions.upgradeWithOperator or the
variant that expects an operator) based on effectiveAccess so the declared
function signature matches the access guard applied (refer to add-upgradeable.ts
variable access, functions.upgrade, and requireAccessControl for where to apply
this change).
In `@packages/core/stellar/src/fungible.ts`:
- Around line 2-3: The mint entrypoint is skipped when access is omitted because
the code returns early in the `case false` branch before emitting mint logic;
update the control flow so `mintable: true` always emits the mint entrypoint
regardless of whether `access` was provided. Concretely, in the function
handling fungible token generation (references: the `access` parameter, the
`mintable` flag, and the helpers `requireAccessControl` / `setAccessControl`)
ensure you compute a canonical access (e.g., default public access or call
`setAccessControl`/`requireAccessControl` as needed) and move the mint-emission
logic out of the early-return path so that when `mintable` is true you always
add the public `mint` entrypoint; apply the same change to the other
permutations mentioned (the block covering lines ~161-209).
In `@packages/core/stellar/src/zip-shared.test.ts`:
- Around line 202-231: The shared dependency list libDependencies currently
unconditionally includes "stellar-governance", causing printContractCargo to add
it to every contract; remove "stellar-governance" from the libDependencies array
and instead add logic in the code path that builds cargo dependencies for a
scaffold to include "stellar-governance" only when the scaffold type indicates
Governor/votes variants (the code that calls printContractCargo or the function
that merges libDependencies into the contract-specific dependencies should
detect scaffold type and append stellar-governance conditionally). Update the
functions printContractCargo and the scaffold dependency assembly to rely on the
revised libDependencies plus this conditional addition so non-governor templates
no longer get the governance crate.
---
Nitpick comments:
In `@packages/core/stellar/src/contract.ts`:
- Around line 255-257: addTopLevelDeclaration currently stores the caller-owned
array reference into this.topLevelDeclarations, allowing external mutation to
alter contract output; change the implementation of addTopLevelDeclaration to
push a defensive copy of the incoming lines (e.g., clone with slice() or spread)
so this.topLevelDeclarations receives an owned array copy and subsequent
external changes to the original lines array won't affect stored declarations.
In `@packages/core/stellar/src/stablecoin.test.ts`:
- Around line 145-159: Update the existing test "throws error when votes and
limitations are both enabled" to also assert the incompatibility when
limitations is set to 'blocklist': call buildStablecoin with votes: true and
limitations: 'blocklist', expect an OptionsError, and assert
error.messages.votes equals 'Votes extension cannot be used with stablecoin
limitations' and error.messages.limitations equals 'Stablecoin limitations
cannot be used with Votes extension' (use the same pattern as the existing
allowlist assertions referencing buildStablecoin and OptionsError).
In `@packages/mcp/src/stellar/tools/non-fungible.test.ts`:
- Around line 42-49: Add a new test-case fixture that sets votes: true so the
branch where votes is enabled is exercised; specifically, in the test named 'all
default' (where the params object is built) add a separate test or modify/create
a fixture variant that uses DeepRequired<z.infer<typeof t.context.schema>>
params with votes: true (and the same other fields: name, symbol, tokenUri,
burnable, enumerable) and assert the expected behaviour, and do the same for the
other test around the 69-76 block to ensure the enabled-votes path is covered.
In `@packages/mcp/src/stellar/tools/stablecoin.test.ts`:
- Around line 41-47: The tests only exercise the votes:false branch in the
stablecoin tests; add a separate fixture where votes: true and assert the
enabled-votes behavior so regressions that ignore votes when enabled will fail.
Specifically, in the test suite around test('all default', ...) create an
additional test case (or modify the existing suite) that supplies params with
votes: true (same shape as DeepRequired<z.infer<typeof t.context.schema>>) and
add assertions that validate the contract/state changes expected when votes are
enabled; do the same for the analogous test near lines 63-69 so both the enabled
and disabled branches of votes are covered.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: f2752c6b-3f40-430b-ab52-46bffb7ad769
⛔ Files ignored due to path filters (7)
packages/cli/src/cli.test.ts.snapis excluded by!**/*.snappackages/core/stellar/src/contract.test.ts.snapis excluded by!**/*.snappackages/core/stellar/src/fungible.test.ts.snapis excluded by!**/*.snappackages/core/stellar/src/governor.test.ts.snapis excluded by!**/*.snappackages/core/stellar/src/non-fungible.test.ts.snapis excluded by!**/*.snappackages/core/stellar/src/stablecoin.test.ts.snapis excluded by!**/*.snappackages/core/stellar/src/zip-rust.compile.test.ts.snapis excluded by!**/*.snap
📒 Files selected for processing (59)
.changeset/curvy-dolls-return.mdpackages/cli/src/cli.test.ts.mdpackages/cli/src/registry.tspackages/common/src/ai/descriptions/stellar.tspackages/common/src/ai/schemas/index.tspackages/common/src/ai/schemas/schemas.test.tspackages/common/src/ai/schemas/stellar.tspackages/core/stellar/src/add-upgradeable.tspackages/core/stellar/src/api.tspackages/core/stellar/src/build-generic.tspackages/core/stellar/src/contract.test.ts.mdpackages/core/stellar/src/contract.tspackages/core/stellar/src/fungible.compile.test.tspackages/core/stellar/src/fungible.test.tspackages/core/stellar/src/fungible.test.ts.mdpackages/core/stellar/src/fungible.tspackages/core/stellar/src/generate/fungible.tspackages/core/stellar/src/generate/governor.tspackages/core/stellar/src/generate/non-fungible.tspackages/core/stellar/src/generate/sources.tspackages/core/stellar/src/generate/stablecoin.tspackages/core/stellar/src/governor.compile.test.tspackages/core/stellar/src/governor.test.tspackages/core/stellar/src/governor.test.ts.mdpackages/core/stellar/src/governor.tspackages/core/stellar/src/index.tspackages/core/stellar/src/kind.tspackages/core/stellar/src/non-fungible.compile.test.tspackages/core/stellar/src/non-fungible.test.tspackages/core/stellar/src/non-fungible.test.ts.mdpackages/core/stellar/src/non-fungible.tspackages/core/stellar/src/print.tspackages/core/stellar/src/stablecoin.compile.test.tspackages/core/stellar/src/stablecoin.test.tspackages/core/stellar/src/stablecoin.test.ts.mdpackages/core/stellar/src/stablecoin.tspackages/core/stellar/src/test.tspackages/core/stellar/src/utils/compile-test.tspackages/core/stellar/src/utils/version.tspackages/core/stellar/src/zip-rust.compile.test.ts.mdpackages/core/stellar/src/zip-scaffold.compile.test.tspackages/core/stellar/src/zip-shared.test.tspackages/core/stellar/src/zip-shared.tspackages/mcp/src/stellar/tools.tspackages/mcp/src/stellar/tools/fungible.test.tspackages/mcp/src/stellar/tools/fungible.tspackages/mcp/src/stellar/tools/governor.test.tspackages/mcp/src/stellar/tools/governor.tspackages/mcp/src/stellar/tools/non-fungible.test.tspackages/mcp/src/stellar/tools/non-fungible.tspackages/mcp/src/stellar/tools/stablecoin.test.tspackages/mcp/src/stellar/tools/stablecoin.tspackages/ui/api/ai-assistant/function-definitions/stellar.tspackages/ui/api/ai-assistant/types/languages.tspackages/ui/src/stellar/App.sveltepackages/ui/src/stellar/FungibleControls.sveltepackages/ui/src/stellar/GovernorControls.sveltepackages/ui/src/stellar/NonFungibleControls.sveltepackages/ui/src/stellar/StablecoinControls.svelte
brozorec
approved these changes
Apr 10, 2026
Contributor
Author
|
@ericglau I think we are ready for a review (if you are required to review before merging) |
ericglau
requested changes
Apr 10, 2026
Member
ericglau
left a comment
ericglau
left a comment
There was a problem hiding this comment.
Just a few comments/questions. Thanks!
Co-authored-by: Eric Lau <ericglau@outlook.com>
Co-authored-by: Eric Lau <ericglau@outlook.com>
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
3 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.
@brozorec, I have reviewed almost everything here, including vote extensions as well.
I haven't reviewed the
Upgradeablepart though, could you take a look at there? If you have time, double checking the votes extension part may be beneficial.I have 2 comments/questions from what I've reviewed, will post them under relevant places.
Keep in mind that, this doesn't include the audit changes. If my comments/questions are not posing big problems, then I can go ahead and also include the audit related changes here.
Additionally, we also need to release the crates in order to pass the tests.
Till then, this is a draft PR.