feat: integrate generic gluon-ergo-sdk and remove local legacy copy#129
feat: integrate generic gluon-ergo-sdk and remove local legacy copy#129sameezy667 wants to merge 3 commits intoStabilityNexus:mainfrom
Conversation
- Remove local SDK copy (lib/gluon-gold-sdk) - Update package.json to use gluon-ergo-sdk from npm - Update all imports from gluon-gold-sdk to gluon-ergo-sdk - Replace legacy method names: - getGoldOracleBox → getOracleBox - transmuteToGold* → transmuteToNeutron* - transmuteFromGold* → transmuteToProton* - Update console logs and error messages - Verified build: zero TypeScript errors
WalkthroughThis PR removes the local gluon-gold-sdk from the repo (source, build config, docs), replaces its local dependency with an external Changes
Sequence Diagram(s)(omitted) Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/lib/components/blockchain/swap/ReactorSwap.tsx (1)
826-844:⚠️ Potential issue | 🟠 MajorAlign the transmutation action keys with the transaction listener.
These branches now execute the renamed neutron/proton transmutation flows, but
calculateExpectedChanges()in this file still only handlestransmute-to-goldandtransmute-from-gold.saveUpTransaction()will therefore persist zero token deltas for both paths, which can leave pending-state and balance-refresh handling blind after a transmutation.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/lib/functions/reactor/handleTransmutation.ts`:
- Around line 257-264: handleTransactionError's INSUFFICIENT_BALANCE branch
doesn't recognize the new action labels "transmute to neutron" and "transmute to
proton" used by handleTransactionSuccess/handleTransactionError, so
insufficient-balance transmutation errors show a generic message; either extend
the switch in handleTransactionError (INSUFFICIENT_BALANCE case) to treat
"transmute to neutron" and "transmute to proton" the same as
"transmutation"/"fission"/"fusion", or change callers
(handleTransactionSuccess/handleTransactionError invocations) to pass a
canonical actionType like "transmutation" instead of the verbose labels—update
all occurrences (e.g., the calls passing "transmute to neutron"/"transmute to
proton") and the switch matching logic in handleTransactionError to ensure the
specialized "Insufficient token balance for transmutation." message is used.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 1603b466-cdad-484f-84ce-ddfe2dd6744d
⛔ Files ignored due to path filters (1)
lib/gluon-gold-sdk/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (25)
lib/gluon-gold-sdk/.gitignorelib/gluon-gold-sdk/.npmignorelib/gluon-gold-sdk/README.mdlib/gluon-gold-sdk/blog.mdlib/gluon-gold-sdk/desktop.inilib/gluon-gold-sdk/next.config.jslib/gluon-gold-sdk/package.jsonlib/gluon-gold-sdk/src/config.tslib/gluon-gold-sdk/src/consts.tslib/gluon-gold-sdk/src/gluon.tslib/gluon-gold-sdk/src/gluonBox.tslib/gluon-gold-sdk/src/goldOracleBox.tslib/gluon-gold-sdk/src/index.tslib/gluon-gold-sdk/src/nodeService.tslib/gluon-gold-sdk/src/serializer.tslib/gluon-gold-sdk/src/txUtils.tslib/gluon-gold-sdk/tsconfig.jsonpackage.jsonsrc/lib/components/blockchain/swap/ReactorSwap.tsxsrc/lib/components/blocks/dashboard/GluonStats.tsxsrc/lib/components/blocks/dashboard/MyStats.tsxsrc/lib/components/blocks/dashboard/VolumeChart.tsxsrc/lib/functions/reactor/handleFission.tssrc/lib/functions/reactor/handleFusion.tssrc/lib/functions/reactor/handleTransmutation.ts
💤 Files with no reviewable changes (17)
- lib/gluon-gold-sdk/README.md
- lib/gluon-gold-sdk/package.json
- lib/gluon-gold-sdk/blog.md
- lib/gluon-gold-sdk/src/gluon.ts
- lib/gluon-gold-sdk/src/index.ts
- lib/gluon-gold-sdk/src/txUtils.ts
- lib/gluon-gold-sdk/src/goldOracleBox.ts
- lib/gluon-gold-sdk/.gitignore
- lib/gluon-gold-sdk/src/config.ts
- lib/gluon-gold-sdk/desktop.ini
- lib/gluon-gold-sdk/src/serializer.ts
- lib/gluon-gold-sdk/next.config.js
- lib/gluon-gold-sdk/tsconfig.json
- lib/gluon-gold-sdk/.npmignore
- lib/gluon-gold-sdk/src/gluonBox.ts
- lib/gluon-gold-sdk/src/nodeService.ts
- lib/gluon-gold-sdk/src/consts.ts
| handleTransactionSuccess(txHash, "transmute to neutron"); | ||
|
|
||
| return { txHash }; | ||
| } catch (error) { | ||
| console.error("TransmuteToGold failed:", error); | ||
| console.error("TransmuteToNeutron failed:", error); | ||
|
|
||
| // Use the error handler for proper classification and toast notification | ||
| const errorDetails = handleTransactionError(error, "transmute to gold"); | ||
| const errorDetails = handleTransactionError(error, "transmute to neutron"); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "# error-handler implementation"
fd 'error-handler\.ts$' src | while read -r file; do
echo "## $file"
sed -n '1,240p' "$file"
done
echo
echo "# relevant action-label usages"
rg -n -C3 'handleTransactionSuccess|handleTransactionError|transmute to neutron|transmute to proton|transmute-to-gold|transmute-from-gold|volatile-to-stable|stable-to-volatile' srcRepository: StabilityNexus/Gluon-Ergo-UI
Length of output: 27164
Update the shared error handler to recognize the new transmutation action labels.
handleTransactionError() and handleTransactionSuccess() now receive "transmute to neutron" and "transmute to proton", but the error handler's INSUFFICIENT_BALANCE customization only checks for "fission", "fusion", and "transmutation" (line 209–218 of error-handler.ts). For insufficient balance errors during transmutation, users will see the generic "Insufficient balance for this transaction." instead of "Insufficient token balance for transmutation." Add cases in the switch statement to handle the new action labels, or standardize on a canonical actionType string like "transmutation" across all calls.
Also applies to: lines 353–360
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/lib/functions/reactor/handleTransmutation.ts` around lines 257 - 264,
handleTransactionError's INSUFFICIENT_BALANCE branch doesn't recognize the new
action labels "transmute to neutron" and "transmute to proton" used by
handleTransactionSuccess/handleTransactionError, so insufficient-balance
transmutation errors show a generic message; either extend the switch in
handleTransactionError (INSUFFICIENT_BALANCE case) to treat "transmute to
neutron" and "transmute to proton" the same as
"transmutation"/"fission"/"fusion", or change callers
(handleTransactionSuccess/handleTransactionError invocations) to pass a
canonical actionType like "transmutation" instead of the verbose labels—update
all occurrences (e.g., the calls passing "transmute to neutron"/"transmute to
proton") and the switch matching logic in handleTransactionError to ensure the
specialized "Insufficient token balance for transmutation." message is used.
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@next.config.ts`:
- Around line 6-8: Remove the now-stale experimental.externalDir setting from
next.config.ts: delete the experimental: { externalDir: true } block and rely on
transpilePackages for the registry dependency (e.g., transpilePackages including
"gluon-ergo-sdk"); if you actually still import modules from outside the repo
root, keep the flag but add a comment explaining that externalDir is required
and why, otherwise remove it to avoid using an unnecessary experimental flag.
- Around line 11-23: The Content-Security-Policy set in the headers() function
currently includes 'unsafe-eval' unconditionally; update headers() so the CSP
value conditionally drops 'unsafe-eval' in production and instead includes
'wasm-unsafe-eval' to permit WebAssembly while keeping strict CSP: build the CSP
string used for the Content-Security-Policy header in headers() (refer to the
headers() function and the Content-Security-Policy header value) so that in
production (e.g. process.env.NODE_ENV === 'production') you do not include
'unsafe-eval' but do include 'wasm-unsafe-eval', whereas in development you may
keep 'unsafe-eval' for tooling; ensure the header value still contains
"script-src 'self' 'unsafe-inline'; object-src 'none';" plus the appropriate
eval token per environment.
In `@package.json`:
- Line 8: The package.json "build" script currently runs "next build" which
defaults to Turbopack in Next.js 16 and will fail when a custom webpack config
exists; update the "build" script to append the --webpack flag (i.e., change the
script referenced by the "build" key) so Next uses webpack, and likewise update
any other build-related npm scripts (e.g., "build:ci" or similar) that call
"next build" to include --webpack; ensure you only alter the script strings and
do not modify other fields.
- Line 37: Replace the wildcard dependency "gluon-ergo-sdk": "*" in package.json
with a concrete published version or a safe semver range (for example
"gluon-ergo-sdk": "^X.Y.Z"); update the dependency entry for "gluon-ergo-sdk"
accordingly, run your package manager (npm install or yarn) to update lockfile,
run the test suite to confirm no regressions, and commit the updated
package.json and lockfile.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0e92ea7c-5931-447d-8f24-7a3cd2c1803c
⛔ Files ignored due to path filters (1)
bun.lockbis excluded by!**/bun.lockb
📒 Files selected for processing (2)
next.config.tspackage.json
| experimental: { | ||
| externalDir: true, | ||
| }, |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
externalDir looks stale after moving the SDK to npm.
transpilePackages already supports external dependencies from node_modules. Since this PR switches gluon-ergo-sdk from a workspace/local package to a registry dependency, keeping experimental.externalDir enabled looks like leftover workspace-era config rather than a current requirement. That's an inference, but I'd remove the experimental flag unless you still resolve imports from outside the repo root. (nextjs.org)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@next.config.ts` around lines 6 - 8, Remove the now-stale
experimental.externalDir setting from next.config.ts: delete the experimental: {
externalDir: true } block and rely on transpilePackages for the registry
dependency (e.g., transpilePackages including "gluon-ergo-sdk"); if you actually
still import modules from outside the repo root, keep the flag but add a comment
explaining that externalDir is required and why, otherwise remove it to avoid
using an unnecessary experimental flag.
| async headers() { | ||
| return [ | ||
| { | ||
| source: '/:path*', | ||
| headers: [ | ||
| { | ||
| key: 'Content-Security-Policy', | ||
| value: "script-src 'self' 'unsafe-eval' 'unsafe-inline'; object-src 'none';", | ||
| }, | ||
| ], | ||
| }, | ||
| ]; | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find and examine next.config.ts
find . -name "next.config.*" -type fRepository: StabilityNexus/Gluon-Ergo-UI
Length of output: 88
🏁 Script executed:
# Search for ergo-lib-wasm usage in the codebase
rg "ergo-lib-wasm" --type ts --type tsx --type js --type jsxRepository: StabilityNexus/Gluon-Ergo-UI
Length of output: 99
🏁 Script executed:
# Check package.json for dependencies
cat package.json | grep -A 50 "dependencies\|devDependencies" | head -100Repository: StabilityNexus/Gluon-Ergo-UI
Length of output: 2035
🏁 Script executed:
# Look for asyncWebAssembly configuration in next.config
rg "asyncWebAssembly" -A 2 -B 2Repository: StabilityNexus/Gluon-Ergo-UI
Length of output: 244
🏁 Script executed:
# Read the next.config.ts file to see the full CSP implementation
cat -n next.config.tsRepository: StabilityNexus/Gluon-Ergo-UI
Length of output: 1349
🌐 Web query:
Next.js Content Security Policy guide WebAssembly wasm-unsafe-eval
💡 Result:
To allow WebAssembly under a strict CSP in Next.js, add 'wasm-unsafe-eval' to your script-src directive (instead of broad **'unsafe-eval'). Next.js explicitly calls this out as the fix for WebAssembly-related CSP violations. [1]
Example (Next.js next.config.js via headers())
// next.config.js
const isDev = process.env.NODE_ENV !== 'production'
const csp = [
"default-src 'self'",
"script-src 'self' 'wasm-unsafe-eval'" + (isDev ? " 'unsafe-eval'" : ""),
"style-src 'self' 'unsafe-inline'",
"img-src 'self' blob: data:",
"font-src 'self'",
"object-src 'none'",
"base-uri 'self'",
"form-action 'self'",
"frame-ancestors 'none'",
"upgrade-insecure-requests",
].join('; ')
module.exports = {
async headers() {
return [{ source: '/(.*)', headers: [{ key: 'Content-Security-Policy', value: csp }] }]
},
}Next.js supports setting headers like this using the headers key in next.config.js. [2]
What wasm-unsafe-eval is
'wasm-unsafe-eval' is a CSP keyword defined in CSP Level 3 and is specifically intended to permit WebAssembly compilation/instantiation that would otherwise be blocked when eval-like behaviors are disallowed. [3][4]
Sources: Next.js CSP guide [1], Next.js headers() config docs [2], W3C CSP Level 3 spec [3], MDN note on requiring 'wasm-unsafe-eval' for WebAssembly under CSP [4].
Fix CSP to remove production 'unsafe-eval' and add 'wasm-unsafe-eval' for WebAssembly support.
The current CSP header includes 'unsafe-eval' unconditionally, which weakens XSS protection in production. With ergo-lib-wasm-browser and ergo-lib-wasm-nodejs as dependencies and asyncWebAssembly enabled, the CSP must also include 'wasm-unsafe-eval' to support WebAssembly initialization in strict CSP environments.
Suggested change
async headers() {
+ const isDev = process.env.NODE_ENV === 'development';
+ const cspHeader = [
+ "default-src 'self'",
+ `script-src 'self' 'unsafe-inline' 'wasm-unsafe-eval'${isDev ? " 'unsafe-eval'" : ''}`,
+ "object-src 'none'",
+ ].join('; ');
+
return [
{
source: '/:path*',
headers: [
{
key: 'Content-Security-Policy',
- value: "script-src 'self' 'unsafe-eval' 'unsafe-inline'; object-src 'none';",
+ value: cspHeader,
},
],
},
];
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| async headers() { | |
| return [ | |
| { | |
| source: '/:path*', | |
| headers: [ | |
| { | |
| key: 'Content-Security-Policy', | |
| value: "script-src 'self' 'unsafe-eval' 'unsafe-inline'; object-src 'none';", | |
| }, | |
| ], | |
| }, | |
| ]; | |
| }, | |
| async headers() { | |
| const isDev = process.env.NODE_ENV === 'development'; | |
| const cspHeader = [ | |
| "default-src 'self'", | |
| `script-src 'self' 'unsafe-inline' 'wasm-unsafe-eval'${isDev ? " 'unsafe-eval'" : ''}`, | |
| "object-src 'none'", | |
| ].join('; '); | |
| return [ | |
| { | |
| source: '/:path*', | |
| headers: [ | |
| { | |
| key: 'Content-Security-Policy', | |
| value: cspHeader, | |
| }, | |
| ], | |
| }, | |
| ]; | |
| }, |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@next.config.ts` around lines 11 - 23, The Content-Security-Policy set in the
headers() function currently includes 'unsafe-eval' unconditionally; update
headers() so the CSP value conditionally drops 'unsafe-eval' in production and
instead includes 'wasm-unsafe-eval' to permit WebAssembly while keeping strict
CSP: build the CSP string used for the Content-Security-Policy header in
headers() (refer to the headers() function and the Content-Security-Policy
header value) so that in production (e.g. process.env.NODE_ENV === 'production')
you do not include 'unsafe-eval' but do include 'wasm-unsafe-eval', whereas in
development you may keep 'unsafe-eval' for tooling; ensure the header value
still contains "script-src 'self' 'unsafe-inline'; object-src 'none';" plus the
appropriate eval token per environment.
| "dev": "next dev --webpack", | ||
| "buildtest": "next build", | ||
| "build": "bun run build:sdk && next build", | ||
| "build": "next build", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's look at the package.json to see lines 7-8 and line 37
cat -n package.json | head -40Repository: StabilityNexus/Gluon-Ergo-UI
Length of output: 1573
🏁 Script executed:
# Check if next.config.ts exists and what webpack config it contains
find . -name "next.config.*" -type f | head -5Repository: StabilityNexus/Gluon-Ergo-UI
Length of output: 88
🏁 Script executed:
# If next.config.ts exists, let's see its content
if [ -f "next.config.ts" ]; then cat -n next.config.ts; elif [ -f "next.config.js" ]; then cat -n next.config.js; fiRepository: StabilityNexus/Gluon-Ergo-UI
Length of output: 1349
🌐 Web query:
Next.js 16 Turbopack default webpack config build failure --webpack flag
💡 Result:
In Next.js 16, Turbopack is the default bundler for next build. If your project has a custom webpack config in next.config.js, Next.js 16 will fail the build on purpose (to avoid silently ignoring/misapplying webpack-only settings under Turbopack). (nextjs.org)
Fix options:
- Opt out and build with Webpack
next build --webpack
# (also available for dev)
next dev --webpackThis keeps your existing webpack(config) { ... } customization working. (nextjs.org)
- Migrate off webpack-only config
Move what you can to theturbopackconfig innext.config.js(note:experimental.turbois being removed in v16). (nextjs.org)
Typical package.json workaround:
{
"scripts": {
"build": "next build --webpack"
}
}Citations:
- 1: https://nextjs.org/docs/app/guides/upgrading/version-16?utm_source=openai
- 2: https://nextjs.org/docs/app/guides/upgrading/version-16?utm_source=openai
- 3: https://nextjs.org/docs/app/api-reference/config/next-config-js/turbopack?utm_source=openai
Add --webpack flag to build scripts.
Next.js 16 uses Turbopack by default, which fails when a custom webpack config is present. This project has webpack configuration in next.config.ts (for symlink support and WebAssembly), so both build scripts need the --webpack flag to avoid build failures. The dev script on line 6 already has this flag.
Suggested changes
- "buildtest": "next build",
+ "buildtest": "next build --webpack",- "build": "next build",
+ "build": "next build --webpack",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "build": "next build", | |
| "build": "next build --webpack", |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` at line 8, The package.json "build" script currently runs "next
build" which defaults to Turbopack in Next.js 16 and will fail when a custom
webpack config exists; update the "build" script to append the --webpack flag
(i.e., change the script referenced by the "build" key) so Next uses webpack,
and likewise update any other build-related npm scripts (e.g., "build:ci" or
similar) that call "next build" to include --webpack; ensure you only alter the
script strings and do not modify other fields.
| "ergo-lib-wasm-nodejs": "^0.28.0", | ||
| "framer-motion": "^11.17.0", | ||
| "gluon-gold-sdk": "file:lib/gluon-gold-sdk", | ||
| "gluon-ergo-sdk": "*", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n package.json | head -50Repository: StabilityNexus/Gluon-Ergo-UI
Length of output: 1930
🌐 Web query:
gluon-ergo-sdk npm package latest version
💡 Result:
I couldn’t find any public npm package named gluon-ergo-sdk (no listing showed up in npm-related indexes/search results).
The closest matching published packages I could verify are:
gluon-gold-sdk— latest published version shown: 1.0.0. [1]@patternglobal/ergo-sdk— latest published version shown: 1.0.0. [1]
Source(s): [1]
Pin gluon-ergo-sdk to a specific version before merging.
The wildcard version specifier * breaks reproducibility and allows any future release to be installed, potentially causing silent breaking changes. Once the npm package is published, replace * with the published version number or a bounded version range (e.g., ^X.Y.Z).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` at line 37, Replace the wildcard dependency "gluon-ergo-sdk":
"*" in package.json with a concrete published version or a safe semver range
(for example "gluon-ergo-sdk": "^X.Y.Z"); update the dependency entry for
"gluon-ergo-sdk" accordingly, run your package manager (npm install or yarn) to
update lockfile, run the test suite to confirm no regressions, and commit the
updated package.json and lockfile.
Addressed Issues:
Completes the mentor's requirement to decouple the frontend from the local
lib/gluon-gold-sdkcopy and prepares the application to use the generic npm package.gluon-ergo-sdkpackage is published to npm.Additional Notes:
lib/gluon-gold-sdk/directory.package.jsonto remove local workspace bindings and build scripts (check:sdk,build:sdk)."gluon-ergo-sdk": "*". (Currently usingbun linklocally; ready to be switched to semantic versioning once the SDK PR is published).gluon-gold-sdktogluon-ergo-sdk.getGoldOracleBox()→getOracleBox(),transmuteToGoldForEip12()→transmuteToNeutronForEip12()).Checklist
AI Usage Disclosure
I have used the following AI models and tools: Claude
Summary by CodeRabbit
Refactor
Chores