feat(paperboy): add paid signal distribution skill

[sonic-mast]

Adds paperboy skill for distributing aibtc.news signals to agents and external audiences.

Subcommands: leaderboard, status, signals, recruit, log-delivery

Pay: 500 sats/placement, 2000 sats/recruit bonus.

Requesting Devin review before upstream PR.

---

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 11 additional findings in Devin Review.

[devin-ai-integration]

🟡 Rune transfer vsize calculation double-counts one P2TR output, overestimating fees

At rune-transfer-builder.ts:219-226, the fee estimation formula (actualOutputCount - 1) * P2TR_OUTPUT_VBYTES + P2WPKH_OUTPUT_VBYTES overcounts by one P2TR output. actualOutputCount includes the OP_RETURN output (already covered by OP_RETURN_VBYTES earlier in the sum), so subtracting 1 should remove the OP_RETURN, leaving only the non-OP_RETURN outputs. However, the formula treats all non-OP_RETURN outputs as P2TR and adds one extra P2WPKH. When there's no rune change output, actual non-OP_RETURN outputs are: 1 P2TR (recipient) + 1 P2WPKH (BTC change). But the formula computes (3-1)=2 P2TR outputs + 1 P2WPKH = 3 outputs, overcounting by 1 P2TR (~43 vbytes). This wastes sats on excess fees but does not cause transaction failures.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 Zest getUserPosition now reads supply from LP token balance instead of reserve data

The getUserPosition method in src/lib/services/defi.service.ts:465-512 was significantly rewritten. Previously it read both supply and borrow from get-user-reserve-data. Now it reads supply from the LP token's get-balance and borrow from get-user-reserve-data's principal-borrow-balance field (instead of current-variable-debt). This is a behavioral change: the old current-a-token-balance from reserve data and the LP token balance may not always return identical values (e.g., during interest accrual). The comment attributes this to a fix in aibtc-mcp-server v1.33.3. The change to principal-borrow-balance from current-variable-debt also changes which borrow figure is reported — principal vs accrued.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 18 additional findings in Devin Review.

[devin-ai-integration]

🚩 skills.json manifest lists 'assess-position' but actual CLI command is 'assess-pool-drift'

In skills.json:752, the hodlmm-risk skill lists assess-position as a subcommand argument, but the actual CLI implementation at hodlmm-risk/hodlmm-risk.ts:296 registers the command as assess-pool-drift. The SKILL.md frontmatter at hodlmm-risk/SKILL.md:8 correctly says assess-pool-drift. This means the manifest was likely generated before the rename or the SKILL.md was updated without regenerating the manifest. Any tool that discovers skills via skills.json would show the wrong subcommand name. Running bun run manifest should fix this.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 18 additional findings in Devin Review.

[devin-ai-integration]

🔴 hodlmm-risk SKILL.md uses invalid tag "read" — must be "read-only"

The hodlmm-risk/SKILL.md frontmatter specifies tags: "l2, read" but "read" is not in the controlled tag vocabulary. Per CONTRIBUTING.md, valid tag values are: l1, l2, read-only, write, mainnet-only, requires-funds, sensitive, infrastructure, defi. The correct tag is "read-only". This also propagates into the generated skills.json manifest at the hodlmm-risk entry.

Suggested change

	---
	tags: "l2, read-only"

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 inscription-builder reveal fee estimation significantly changed — verify against real transactions

The reveal fee estimation in inscription-builder.ts:415-419 was substantially rewritten. The old code used revealScript.script.byteLength / 4 (the P2TR output script, ~34 bytes → ~9 vbytes). The new code uses the tap leaf script size (which contains the full inscription body) with a 1.25x multiplier plus 80 vbytes overhead. For a 1KB inscription, old estimate was ~9 vbytes; new is ~(1024/4*1.25)+80 = ~400 vbytes. This is a much more accurate estimate but represents a major behavioral change for existing users — their estimate-fee results and required commit amounts will be significantly higher. The fix is correct (old estimates were severely underestimating), but it's a breaking change in economic behavior worth calling out.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 22 additional findings in Devin Review.

[devin-ai-integration]

🔴 Session restored from disk never starts the auto-lock timer

restoreSessionFromDisk at src/lib/services/wallet-manager.ts:364-396 creates a new in-memory session with an expiresAt field but never calls startAutoLockTimer(). In contrast, the unlock() method at line 287 always calls this.startAutoLockTimer(config.autoLockTimeout) after creating the session. This means a session restored from disk will never auto-lock — it remains unlocked indefinitely in the current process, even when the original unlock had a finite timeout. The expiresAt in the session object is only checked at disk-restore time, not enforced in-process.

Suggested change

	// Restore the in-memory session so subsequent in-process calls also work
	const now = new Date();
	this.session = {
	walletId,
	account,
	unlockedAt: now,
	expiresAt,
	};
	// Restore the in-memory session so subsequent in-process calls also work
	const now = new Date();
	this.session = {
	walletId,
	account,
	unlockedAt: now,
	expiresAt,
	};
	// Start auto-lock timer if the restored session has an expiry
	if (expiresAt) {
	const remainingMs = expiresAt.getTime() - now.getTime();
	const remainingMinutes = Math.max(Math.ceil(remainingMs / 60000), 1);
	this.startAutoLockTimer(remainingMinutes);
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 HODLMM addLiquiditySimple uses PostConditionMode.Allow — expected but worth noting

The addHodlmmLiquiditySimple and withdrawHodlmmLiquiditySimple methods in bitflow.service.ts both use PostConditionMode.Allow with empty post conditions. This means the Stacks transaction can move any tokens without guard rails. The comment at bitflow/AGENT.md documents this is intentional for HODLMM operations. However, this contrasts with the swap function which uses the SDK's built-in post conditions. For high-value liquidity operations, the lack of post conditions means a malicious or buggy contract could drain more tokens than expected.

---

Was this helpful? React with 👍 or 👎 to provide feedback.