[Stellar] Add toggle to switch from default to explicit trait implementation #728
Conversation
Co-authored-by: Eric Lau <[email protected]>
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe PR introduces an Changes
Sequence Diagram(s)sequenceDiagram
participant User as User/Config
participant Builder as Contract Builder
participant AC as Access Control
participant Gen as Code Generator
User->>Builder: buildFungible({explicitImplementations: true})
activate Builder
Builder->>Builder: addBase(c, name, symbol, pausable, true)
note over Builder: Set trait tags to ['contractimpl']<br/>conditionally import types
alt explicitImplementations = true
Builder->>Gen: addTraitForEachFunctions(trait,<br/>fungibleTokenTraitFunctions)
note over Gen: Generate explicit<br/>function implementations
else explicitImplementations = false
Builder->>Gen: Add default_impl macro
note over Gen: Use default_impl<br/>+ contractimpl
end
Builder->>Builder: addMintable(c, access, pausable, true)
Builder->>AC: requireAccessControl(..., true)
activate AC
AC->>AC: setAccessControl(..., true)
alt explicitImplementations = true
AC->>Gen: defineFunctions(ownableFunctions)
AC->>Builder: addTraitForEachFunctions(trait, fns)
else
AC->>Gen: Use default_impl blocks
end
deactivate AC
deactivate Builder
Gen-->>User: Generated Rust code<br/>(explicit or default mode)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related issues
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
Comment |
CoveMB
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/core/stellar/src/add-pausable.ts (1)
8-36: Dropdefault_implimport when explicit implementations are requested.With
explicitImplementationsturned on (and pausable enabled), we still adduse stellar_macros::default_impl;even though no#[default_impl]tag remains. That leaves an unused import in the generated contract, which breaks builds under the-D warningsflag (our compile suite runs with warnings-as-errors) and defeats the goal of avoiding the macro in explicit mode. Please gate the import on!explicitImplementations.- c.addUseClause('stellar_macros', 'default_impl'); + if (!explicitImplementations) { + c.addUseClause('stellar_macros', 'default_impl'); + }
🧹 Nitpick comments (4)
packages/ui/src/stellar/TraitImplementationSection.svelte (1)
15-19: Consider simplifying the description text.The description is quite verbose and repeats information that's already in the radio button labels and tooltips.
Consider a more concise version:
<p> - Show explicit traits to override specific functions with custom behavior instead of relying on #[default_impl] macro - that auto-generates stub bodies for every function in the trait that you do not explicitly implement inside that - impl block + Choose how trait methods are generated: use the #[default_impl] macro for automatic stubs, or generate explicit function bodies for full control. </p>packages/core/stellar/src/stablecoin.test.ts (1)
126-128: Consider testing explicit implementations with combined features.The test case only tests
explicitImplementations: truein isolation. To ensure the feature works correctly with other options (mintable, burnable, pausable, upgradeable, access control), consider adding a combined test case similar to the "stablecoin full" test variants.Example addition:
+testStablecoin('stablecoin explicit implementations with features', { + explicitImplementations: true, + premint: '2000', + access: 'roles', + limitations: 'allowlist', + burnable: true, + mintable: true, + pausable: true, +});packages/core/stellar/src/fungible.compile.test.ts (1)
204-216: Consider testing explicit implementations with combined features.The compilation test only verifies
explicitImplementations: truein isolation. Since this is a compilation test that verifies Rust code generation, consider adding a test case that combines explicit implementations with other features (mintable, burnable, pausable, upgradeable) to ensure the generated code compiles correctly in realistic scenarios.Example addition:
+test.serial( + 'compilation fungible explicit implementations with features', + runRustCompilationTest( + buildFungible, + { + kind: 'Fungible', + name: 'MyToken', + symbol: 'MTK', + explicitImplementations: true, + premint: '2000', + burnable: true, + mintable: true, + pausable: true, + upgradeable: true, + }, + { snapshotResult: false }, + ), +);packages/core/stellar/src/non-fungible.compile.test.ts (1)
168-187: Consider testing explicit implementations with combined features.Similar to the fungible compilation test, this test only verifies
explicitImplementations: truein isolation. Consider adding a test case that combines explicit implementations with other features to ensure comprehensive compilation coverage.Example addition:
+test.serial( + 'compilation nonfungible explicit implementations with features', + runRustCompilationTest( + buildNonFungible, + { + kind: 'NonFungible', + name: 'MyNFT', + symbol: 'MNFT', + burnable: true, + enumerable: true, + consecutive: false, + pausable: true, + upgradeable: true, + mintable: true, + sequential: true, + explicitImplementations: true, + }, + { snapshotResult: false }, + ), +);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
packages/core/stellar/src/fungible.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!**/*.snap
📒 Files selected for processing (30)
packages/common/src/ai/descriptions/stellar.ts(1 hunks)packages/core/stellar/src/add-pausable.ts(2 hunks)packages/core/stellar/src/add-upgradeable.ts(2 hunks)packages/core/stellar/src/common-options.ts(3 hunks)packages/core/stellar/src/contract.ts(1 hunks)packages/core/stellar/src/fungible.compile.test.ts(1 hunks)packages/core/stellar/src/fungible.test.ts(1 hunks)packages/core/stellar/src/fungible.test.ts.md(2 hunks)packages/core/stellar/src/fungible.ts(7 hunks)packages/core/stellar/src/generate/fungible.ts(1 hunks)packages/core/stellar/src/generate/non-fungible.ts(1 hunks)packages/core/stellar/src/generate/stablecoin.ts(1 hunks)packages/core/stellar/src/non-fungible.compile.test.ts(1 hunks)packages/core/stellar/src/non-fungible.test.ts(1 hunks)packages/core/stellar/src/non-fungible.test.ts.md(1 hunks)packages/core/stellar/src/non-fungible.ts(10 hunks)packages/core/stellar/src/set-access-control.ts(6 hunks)packages/core/stellar/src/stablecoin.compile.test.ts(1 hunks)packages/core/stellar/src/stablecoin.test.ts(1 hunks)packages/core/stellar/src/stablecoin.test.ts.md(2 hunks)packages/core/stellar/src/stablecoin.ts(2 hunks)packages/mcp/src/stellar/schemas.ts(1 hunks)packages/mcp/src/stellar/tools/fungible.test.ts(1 hunks)packages/mcp/src/stellar/tools/fungible.ts(2 hunks)packages/mcp/src/stellar/tools/non-fungible.test.ts(1 hunks)packages/mcp/src/stellar/tools/stablecoin.test.ts(1 hunks)packages/ui/src/stellar/FungibleControls.svelte(2 hunks)packages/ui/src/stellar/NonFungibleControls.svelte(2 hunks)packages/ui/src/stellar/StablecoinControls.svelte(2 hunks)packages/ui/src/stellar/TraitImplementationSection.svelte(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-11-03T12:18:33.779Z
Learnt from: typicalHuman
Repo: OpenZeppelin/contracts-wizard PR: 715
File: packages/core/solidity/src/stablecoin.ts:74-77
Timestamp: 2025-11-03T12:18:33.779Z
Learning: In packages/core/solidity/src/stablecoin.ts, the ERC20Restricted base contract from openzeppelin/community-contracts provides a default implementation of isUserAllowed that returns true for non-BLOCKED users (blocklist logic). Only allowlist mode needs to override isUserAllowed to check for Restriction.ALLOWED instead. Blocklist mode uses the default implementation without override.
Applied to files:
packages/core/stellar/src/stablecoin.test.tspackages/core/stellar/src/stablecoin.ts
📚 Learning: 2025-08-15T23:23:13.097Z
Learnt from: ernestognw
Repo: OpenZeppelin/contracts-wizard PR: 609
File: packages/core/solidity/src/signer.ts:31-38
Timestamp: 2025-08-15T23:23:13.097Z
Learning: In OpenZeppelin contracts-wizard, the `setUpgradeableAccount` function deliberately sets `c.upgradeable = false` after upgradeable setup to exclude EIP712Upgradeable and ERC7739Upgradeable variants (avoiding per-call SLOAD overhead). This architectural pattern necessitates manual `_disableInitializers()` setup in both account.ts and signer.ts since the standard upgradeable constructor logic doesn't apply when upgradeability is disabled post-setup.
Applied to files:
packages/core/stellar/src/add-upgradeable.ts
📚 Learning: 2025-08-20T20:23:30.259Z
Learnt from: ericglau
Repo: OpenZeppelin/contracts-wizard PR: 609
File: packages/core/solidity/src/set-upgradeable.ts:0-0
Timestamp: 2025-08-20T20:23:30.259Z
Learning: In OpenZeppelin contracts-wizard, upgradeable contracts use two different strategies for Initializable imports: Account contracts directly import from contracts-upgradeable/proxy/utils/Initializable.sol for explicit clarity, while other upgradeable contracts (ERC20, ERC721, Governor, etc.) use helpers to automatically transpile imports to upgradeable versions. This architectural separation is intentional due to the special ERC-4337 requirements of account contracts.
Applied to files:
packages/core/stellar/src/add-upgradeable.ts
📚 Learning: 2025-09-18T20:17:09.709Z
Learnt from: ericglau
Repo: OpenZeppelin/contracts-wizard PR: 652
File: packages/mcp/src/confidential/schemas.ts:40-46
Timestamp: 2025-09-18T20:17:09.709Z
Learning: MCP tool schemas for confidential contracts can be more restrictive than the core API. For the votes field in confidential fungible tokens, the MCP schema only accepts 'blocknumber' or 'timestamp' strings because undefined behaves functionally equivalent to false, eliminating the need to explicitly accept boolean values in the tool definition.
Applied to files:
packages/mcp/src/stellar/schemas.ts
🧬 Code graph analysis (11)
packages/core/stellar/src/contract.ts (1)
packages/core/stellar/src/fungible.ts (1)
functions(269-359)
packages/core/stellar/src/stablecoin.compile.test.ts (2)
packages/core/stellar/src/utils/compile-test.ts (1)
runRustCompilationTest(40-69)packages/core/stellar/src/stablecoin.ts (1)
buildStablecoin(45-55)
packages/core/stellar/src/add-pausable.ts (2)
packages/core/stellar/src/contract.ts (1)
ContractBuilder(74-283)packages/core/stellar/src/set-access-control.ts (2)
Access(8-8)requireAccessControl(78-137)
packages/core/stellar/src/non-fungible.compile.test.ts (2)
packages/core/stellar/src/utils/compile-test.ts (1)
runRustCompilationTest(40-69)packages/core/stellar/src/non-fungible.ts (1)
buildNonFungible(65-128)
packages/core/stellar/src/add-upgradeable.ts (2)
packages/core/stellar/src/contract.ts (1)
ContractBuilder(74-283)packages/core/stellar/src/set-access-control.ts (2)
Access(8-8)requireAccessControl(78-137)
packages/mcp/src/stellar/schemas.ts (1)
packages/common/src/ai/descriptions/stellar.ts (1)
stellarCommonDescriptions(11-17)
packages/core/stellar/src/fungible.compile.test.ts (2)
packages/core/stellar/src/utils/compile-test.ts (1)
runRustCompilationTest(40-69)packages/core/stellar/src/fungible.ts (1)
buildFungible(58-89)
packages/core/stellar/src/non-fungible.ts (6)
packages/core/stellar/src/add-pausable.ts (1)
addPausable(7-50)packages/core/stellar/src/add-upgradeable.ts (1)
addUpgradeable(7-49)packages/core/stellar/src/set-access-control.ts (3)
setAccessControl(18-73)Access(8-8)requireAccessControl(78-137)packages/core/stellar/src/contract.ts (1)
ContractBuilder(74-283)packages/core/stellar/src/utils/define-functions.ts (1)
defineFunctions(9-16)packages/core/stellar/src/common-options.ts (1)
getSelfArg(39-41)
packages/core/stellar/src/stablecoin.ts (2)
packages/core/stellar/src/contract.ts (1)
ContractBuilder(74-283)packages/core/stellar/src/set-access-control.ts (2)
Access(8-8)requireAccessControl(78-137)
packages/core/stellar/src/fungible.ts (5)
packages/core/stellar/src/utils/convert-strings.ts (1)
toByteArray(28-34)packages/core/stellar/src/add-pausable.ts (1)
addPausable(7-50)packages/core/stellar/src/add-upgradeable.ts (1)
addUpgradeable(7-49)packages/core/stellar/src/set-access-control.ts (3)
setAccessControl(18-73)Access(8-8)requireAccessControl(78-137)packages/core/stellar/src/contract.ts (1)
ContractBuilder(74-283)
packages/core/stellar/src/set-access-control.ts (3)
packages/core/stellar/src/contract.ts (1)
ContractBuilder(74-283)packages/core/stellar/src/utils/define-functions.ts (1)
defineFunctions(9-16)packages/core/stellar/src/common-options.ts (1)
getSelfArg(39-41)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build (stellar, compile)
- GitHub Check: build (solidity, default)
🔇 Additional comments (35)
packages/mcp/src/stellar/schemas.ts (1)
27-27: LGTM! Schema addition follows the established pattern.The new
explicitImplementationsfield is properly typed as an optional boolean and includes a description from the common descriptions. It will be inherited by all contract schemas through the spread operator.packages/mcp/src/stellar/tools/fungible.test.ts (1)
50-50: LGTM! Test coverage expanded appropriately.The addition of
explicitImplementations: trueto the comprehensive test case ensures the new field is validated through the MCP tool pipeline.packages/mcp/src/stellar/tools/fungible.ts (1)
13-24: LGTM! Parameter propagation is correct.The
explicitImplementationsparameter is properly destructured from the input and passed through to theFungibleOptions, following the established pattern for other optional fields.Also applies to: 35-35
packages/mcp/src/stellar/tools/non-fungible.test.ts (1)
52-52: LGTM! Consistent test coverage.The addition mirrors the fungible test expansion and ensures the new field is validated for non-fungible tokens.
packages/mcp/src/stellar/tools/stablecoin.test.ts (1)
52-52: LGTM! Complete test coverage.This completes the test coverage expansion across all three token types (fungible, non-fungible, and stablecoin).
packages/core/stellar/src/contract.ts (1)
188-190: LGTM! Useful helper for bulk trait function additions.This convenience method cleanly handles batch-adding trait functions, which aligns well with the explicit implementations feature where multiple trait methods need to be registered at once.
packages/core/stellar/src/common-options.ts (3)
10-14: LGTM!The addition of
explicitImplementations: falsetocontractDefaultsis correct and ensures backward compatibility by making explicit trait implementations opt-in.
20-23: LGTM!The interface extension properly adds
explicitImplementationsas an optional boolean property, maintaining consistency with other common contract options.
31-37: LGTM!The propagation of
explicitImplementationsinwithCommonContractDefaultsfollows the established pattern and correctly applies the nullish coalescing operator.packages/core/stellar/src/set-access-control.ts (6)
1-3: LGTM!The new imports
defineFunctionsandgetSelfArgare properly used in the function definitions at the end of the file.
18-44: LGTM!The
setAccessControlfunction properly implements the explicit implementations feature for ownable:
- Default parameter value maintains backward compatibility
- Tag switching correctly omits
default_implfor explicit implementations- Conditional use of
addTraitForEachFunctionsvsaddTraitImplBlockis appropriate
46-73: LGTM!The roles access control path correctly mirrors the ownable implementation pattern with proper tag switching and conditional trait wiring. The addition of the
Symbolimport on line 48 ensures it's available for the access control functions.
78-137: LGTM!The
requireAccessControlfunction properly accepts and propagates theexplicitImplementationsparameter tosetAccessControl, maintaining backward compatibility with the default value.
139-157: LGTM!The
ownableFunctionsdefinitions are correct and complete, properly delegating to theownablemodule functions with appropriate signatures.
159-223: LGTM!The
accessControlFunctionsdefinitions are comprehensive and correctly delegate to theaccess_controlmodule with appropriate signatures and return types.packages/core/stellar/src/generate/stablecoin.ts (1)
8-20: LGTM!The addition of
explicitImplementations: booleansto the stablecoin blueprint correctly follows the pattern of other boolean options and will generate appropriate test variants.packages/core/stellar/src/fungible.test.ts (1)
101-103: LGTM!The new test case properly exercises the explicit trait implementations feature and follows the established testing pattern.
packages/core/stellar/src/stablecoin.compile.test.ts (1)
161-173: LGTM!The new compilation test for explicit trait implementations follows the established pattern and will verify that the generated code compiles successfully.
packages/ui/src/stellar/NonFungibleControls.svelte (2)
10-10: LGTM!The import of
TraitImplementationSectionis appropriate for exposing the explicit implementations toggle in the UI.
56-56: LGTM!The integration of
TraitImplementationSectionwith two-way binding toopts.explicitImplementationsfollows the established pattern and properly exposes the configuration option in the UI.packages/core/stellar/src/non-fungible.test.ts (1)
156-158: LGTM!The new test case properly exercises the explicit trait implementations feature for non-fungible tokens and follows the established testing pattern.
packages/core/stellar/src/stablecoin.ts (2)
45-55: LGTM!The
buildStablecoinfunction correctly propagatesallOpts.explicitImplementationstoaddLimitations.
57-97: LGTM!The
addLimitationsfunction properly:
- Accepts the new
explicitImplementationsparameter- Propagates it to both
requireAccessControlcalls for add and remove functionsThis ensures that limitation functions respect the explicit implementations mode when access control is applied.
packages/ui/src/stellar/FungibleControls.svelte (1)
9-9: LGTM: Clean integration of trait implementation toggle.The TraitImplementationSection is properly imported and rendered with two-way binding to opts.explicitImplementations. The placement between Settings and Features sections is consistent with the other UI controls (StablecoinControls and NonFungibleControls).
Also applies to: 48-49
packages/ui/src/stellar/StablecoinControls.svelte (1)
10-10: LGTM: Consistent UI integration.The TraitImplementationSection integration follows the same pattern as FungibleControls.svelte, maintaining consistency across the UI components.
Also applies to: 49-50
packages/core/stellar/src/add-upgradeable.ts (2)
7-7: LGTM: Function signature properly updated.The
explicitImplementationsparameter is correctly added to the function signature and aligns with the broader changes across the codebase (e.g.,addPausable,setAccessControl).
37-48: LGTM: Parameter correctly threaded through.The
explicitImplementationsparameter is properly passed torequireAccessControlas the final argument, matching the updated signature. The parameter defaults tofalseinrequireAccessControl, maintaining backward compatibility.packages/core/stellar/src/generate/fungible.ts (1)
18-18: Mathematical claim verified; actual performance impact requires testing.The
explicitImplementations: booleansaddition does exactly double the permutations (from 96 to 192). The blueprint generates: 2^5 boolean fields × 3 access options × 2 info options = 192 permutations (vs. 96 before).However, the original test path is incorrect—tests are at
packages/core/stellar/src/fungible.test.tsandfungible.compile.test.ts, not in thegenerate/subdirectory. Whether this doubling causes "significant" test slowdown is speculative without actual execution metrics.To properly verify impact, run the actual tests and compare execution times before/after the change.
packages/core/stellar/src/generate/non-fungible.ts (1)
20-20: The performance concern does not apply to the test suite.The test files use manual snapshot testing with hand-selected option combinations, not the generator functions. The
generateNonFungibleOptionsgenerator is defined but is not called anywhere in the test suite. AddingexplicitImplementations: booleansincreases the mathematical permutation space, but since tests don't iterate through all permutations, there is no actual test performance impact. The suggested verification command calculates the permutation count mathematically but doesn't measure real test execution time, as tests don't use the generators.Likely an incorrect or invalid review comment.
packages/core/stellar/src/fungible.ts (6)
15-26: LGTM: explicitImplementations added to defaults.The flag is correctly added to the defaults object, inheriting from
commonDefaults.explicitImplementations. This maintains backward compatibility while enabling the new feature.
58-89: LGTM: Consistent flag propagation throughout buildFungible.The
explicitImplementationsflag is correctly threaded through all helper functions (addBase,addPausable,addUpgradeable,addBurnable,addMintable,setAccessControl). This ensures the feature is applied consistently across all contract components.
91-135: LGTM: addBase correctly implements conditional trait generation.The function properly handles both explicit and default implementations:
- Line 104:
default_implmacro imported only when needed- Lines 109-111:
Addressimported when required by explicit functions or pausable overrides- Line 116: Trait tags conditionally include
default_impl- Lines 122-124: Explicit functions added when flag is true
- Lines 126-134: Pausable overrides work correctly in both modes
The conditional import at lines 109-111 correctly covers both cases where
Addressis needed: when explicit implementations require it for trait function signatures, and when pausable overrides require it fortransfer/transfer_fromfunctions.
137-178: LGTM: addMintable correctly propagates explicitImplementations.The flag is properly passed to
requireAccessControlin both the ownable (line 145) and roles (lines 155-166) cases, maintaining consistency with the access control pattern used inadd-pausable.tsandadd-upgradeable.ts.
180-206: LGTM: addBurnable correctly handles three implementation modes.The function properly handles the interaction between
pausableandexplicitImplementations:
- When
pausable: explicit functions with pause guards (lines 191-198)- When
explicitImplementations && !pausable: explicit functions without guards (lines 199-200)- When neither: default implementation with
default_impltag (lines 201-205)The if-else chain correctly prioritizes pausable behavior when both flags are true, which is appropriate since pausability requires explicit function overrides.
361-373: LGTM: Function lists are complete and correctly defined.The
fungibleTokenTraitFunctionslist (lines 361-371) includes all nine FungibleToken trait methods, andfungibleBurnableFunctions(line 373) includes both burnable methods. These lists are properly used in the conditional logic at lines 123 and 200 to inject explicit implementations when the flag is enabled.
…ntracts-wizard into stellar-default_impl_attribute
2 participants
Fixes #706
Summary
Enable UI and tooling to use explicit Soroban trait implementations instead of relying solely on
#[default_impl], adding regression coverage and docs for the new option.Motivation / Context
Contract authors asked for a way to inspect and customize every generated Soroban trait function instead of depending on
#[default_impl]. This work exposes that capability in the builders, UI, and MCP tools without changing the default experience.Changes
Description
packages/core/stellar/src/common-options.ts:10-36and the builder defaults now carry anexplicitImplementationsflag so every contract kind can opt in to non-macro trait bodies.packages/core/stellar/src/contract.ts:188-192introducesaddTraitForEachFunctions, letting trait mixins add all functions programmatically when macros are disabled.packages/core/stellar/src/set-access-control.ts:18-235,packages/core/stellar/src/add-pausable.ts:4-44,packages/core/stellar/src/add-upgradeable.ts:4-45) accept the flag, generate Ownable/AccessControl function bodies, and still enforce the same role/owner checks.packages/core/stellar/src/fungible.ts:25-210,packages/core/stellar/src/non-fungible.ts:28-305,packages/core/stellar/src/stablecoin.ts:48-101) and update generation blueprints so option sweeps include the new mode.packages/ui/src/stellar/TraitImplementationSection.svelte:1-33plus imports in each controls file) while schemas/prompts describe and validate it (packages/mcp/src/stellar/schemas.ts:24-35,packages/mcp/src/stellar/tools/fungible.ts:10-40,packages/common/src/ai/descriptions/stellar.ts:12-20).packages/core/stellar/src/*.compile.test.ts,packages/core/stellar/src/*.test.ts/.md,packages/mcp/src/stellar/tools/*.test.ts).Affected Functions
packages/core/stellar/src/contract.ts:188— newaddTraitForEachFunctionshelper to bulk-attach trait methods when macros are skipped.packages/core/stellar/src/set-access-control.ts:18—setAccessControlaccepts the explicit flag and adds per-function trait impls for Ownable/AccessControl when needed.packages/core/stellar/src/set-access-control.ts:84—requireAccessControlforwards the explicit flag so pausable/upgradeable traits stay consistent.packages/core/stellar/src/add-pausable.ts:4&packages/core/stellar/src/add-upgradeable.ts:4— feature mixins now require the explicit flag and pass it through to access control.packages/core/stellar/src/fungible.ts:63&:137— base, burnable, and mintable helpers emit explicit trait functions when requested.packages/core/stellar/src/non-fungible.ts:91&:212— non-fungible base, burnable/enumerable/consecutive modules support explicit implementations.packages/core/stellar/src/stablecoin.ts:48— limitation helpers forward the flag so allow/blocklist operations can be emitted explicitly.Security Impact
requireAccessControlfor gating.Testing
explicitImplementationsenabled (packages/core/stellar/src/fungible.compile.test.ts,non-fungible.compile.test.ts,stablecoin.compile.test.ts).packages/core/stellar/src/*.test.ts,.md,.snap, andpackages/mcp/src/stellar/tools/*.test.ts).Manual verification:
#[default_impl]and shows explicit bodies.pnpm test --filter='packages/core/stellar/src/*explicit*'and the relevant MCP tool tests to ensure the new flag compiles cleanly.Backward Compatibility
#[default_impl]unless the new toggle is enabled.