@bananapus/suckers-v6 0.0.69 → 0.0.71

package/README.md

@@ -64,6 +64,7 @@ That means every bridge path has two trust surfaces:
 - do not reason about suckers as if they were generic ERC-20 bridges
 - root ordering and message delivery semantics matter as much as proof format
 - token mapping is part of the economic invariant
+- peer contexts are merged only when they share both currency and decimals; same-currency contexts with different decimals are kept separate and valued independently at read time, never summed across precisions
 - emergency and deprecation paths are part of normal operational safety
 
 ## Where State Lives

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bananapus/suckers-v6",
-  "version": "0.0.69",
+  "version": "0.0.71",
   "license": "MIT",
   "repository": {
     "type": "git",
@@ -26,7 +26,7 @@
   },
   "dependencies": {
     "@arbitrum/nitro-contracts": "3.2.0",
-    "@bananapus/core-v6": "^0.0.78",
+    "@bananapus/core-v6": "^0.0.81",
     "@bananapus/permission-ids-v6": "^0.0.28",
     "@chainlink/contracts-ccip": "1.6.4",
     "@chainlink/local": "0.2.7",

package/src/JBSucker.sol

@@ -545,12 +545,18 @@ abstract contract JBSucker is ERC2771Context, JBPermissioned, Initializable, ERC
                     _cachedCurrencyOf[contextToken] = contextCurrency;
                 }
 
-                // Accumulate into an existing same-currency entry, or append a new one. The context set is small
-                // (one entry per distinct local currency), so a linear scan is cheaper than a mapping.
+                // Accumulate into an existing entry that matches on BOTH currency AND decimals, or append a new one.
+                // The decimals must match: `surplus`/`balance` are raw, un-valued token amounts, so two contexts that
+                // share a currency but carry different decimals (e.g. a 6-decimal and an 18-decimal representation of
+                // the same currency) are on different scales and CANNOT be summed directly — doing so would corrupt
+                // the
+                // aggregate. Keeping them as separate entries lets the read side (`remoteSurplusOf` -> `_valued`)
+                // decimal-adjust each one independently before summing. The context set is small (one entry per
+                // distinct local currency+decimals), so a linear scan is cheaper than a mapping.
                 uint256 numStored = _peerContexts.length;
                 bool merged;
                 for (uint256 j; j < numStored;) {
-                    if (_peerContexts[j].currency == contextCurrency) {
+                    if (_peerContexts[j].currency == contextCurrency && _peerContexts[j].decimals == ctx.decimals) {
                         _peerContexts[j].surplus = _saturatingAddU128(_peerContexts[j].surplus, ctx.surplus);
                         _peerContexts[j].balance = _saturatingAddU128(_peerContexts[j].balance, ctx.balance);
                         merged = true;
@@ -1293,9 +1299,8 @@ abstract contract JBSucker is ERC2771Context, JBPermissioned, Initializable, ERC
         // Record the balance before the cash out for the sanity check.
         uint256 balanceBefore = _balanceOf({token: token, addr: address(this)});
 
-        // Cash out the project tokens for terminal tokens. Suckers are a transparent value-mover (the bridge
-        // accounting is the entirety of their function) — they're not a fee-paying entry point for any referrer,
-        // so `referralProjectId: 0` is correct.
+        // Cash out the project tokens for terminal tokens. Suckers are a transparent value-mover; the bridge
+        // accounting is the entirety of their function.
         reclaimedAmount = terminal.cashOutTokensOf({
             holder: address(this),
             projectId: cachedProjectId,
@@ -1303,8 +1308,7 @@ abstract contract JBSucker is ERC2771Context, JBPermissioned, Initializable, ERC
             tokenToReclaim: token,
             minTokensReclaimed: minTokensReclaimed,
             beneficiary: payable(address(this)),
-            metadata: bytes(""),
-            referralProjectId: 0
+            metadata: bytes("")
         });
 
         // Sanity check to make sure we received the expected amount.

package/src/structs/JBLeaf.sol

@@ -6,11 +6,9 @@ pragma solidity ^0.8.0;
 /// @custom:member beneficiary The beneficiary of the leaf.
 /// @custom:member projectTokenCount The number of project tokens to claim.
 /// @custom:member terminalTokenAmount The amount of terminal tokens to claim.
-/// @custom:member metadata Opaque, caller-defined attribution payload that travels with the leaf inside the merkle
-/// root. Use cases include cross-chain referral split hooks tagging a leaf with `(originChainId, referralProjectId)`
-/// so the destination contract can settle the bridged value atomically. The sucker protocol itself never inspects
-/// this field — it's covered by the leaf hash, so receivers can trust the value once the merkle proof verifies.
-/// Pass `bytes32(0)` when no attribution context is needed.
+/// @custom:member metadata Opaque, caller-defined payload that travels with the leaf inside the merkle root. The
+/// sucker protocol itself never inspects this field — it's covered by the leaf hash, so receivers can trust the value
+/// once the merkle proof verifies. Pass `bytes32(0)` when no extra claim context is needed.
 struct JBLeaf {
     uint256 index;
     bytes32 beneficiary;