Skip to content

Label restored trade-limit macro values as historical - #86

Closed
hiciefte wants to merge 2 commits into
mainfrom
content/historical-trade-limit-macros
Closed

hiciefte wants to merge 2 commits into
mainfrom
content/historical-trade-limit-macros

Conversation

@hiciefte

Copy link
Copy Markdown
Collaborator

Addresses migration note archived-bisq1-trade-limit-macros ("Trade limits: restored macro values are historical"), which lists 23 articles.

Where the values come from

The 0.0624 BTC and 0.50 BTC figures are not written in the article sources. Each of the 23 articles contains only a macro call, kept as <span class="wiki-template-gap">…{{MaxTradeSizeBisq1}}…</span> (or {{MaxTradeSizeAltcoin}} on Main Page and Templates as macros). At build time scripts/lib/archived-templates.mjs replaces each call with the value of the archived template, recorded in migration/template-renderings-20261014.json:

Template Archived value Template revision Placements
MaxTradeSizeBisq1 (archive-templates/644.wiki.txt) 0.0624 BTC 3891, 30 January 2025 26 in 23 articles
MaxTradeSizeAltcoin (archive-templates/645.wiki.txt) 0.50 BTC 3893, 30 January 2025 2 (Main Page, Templates as macros)

Change

A render-time label, not an article wording change. Each of these 28 expansions keeps its archived value and its existing "2026 source" link, followed by:

(historical wiki value; check the limit shown in Bisq 1)

The link goes to the migration note already shown, open, at the top of each of these pages. To make that possible, each migration-note section now has an id (migration-note-<note id>) in src/components/SourceHistory.astro. The renderer throws if a labelled template ever appears on a page that does not show the note, so the link cannot point nowhere.

The note itself gains two sentences and two sources (second commit, from review):

In Bisq 1, the payment account screen shows the account's limits under Limitations, and the create-offer screen does not accept a larger amount. Tikkie scales its own limit instead: under v1.10.11 it is at most 0.00625 BTC, so the 0.0624 BTC shown on the Tikkie page does not apply.

Example, Zelle: "Maximum BTC per Trade: 0.0624 BTC2026 source" → "Maximum BTC per Trade: 0.0624 BTC2026 source (historical wiki value; check the limit shown in Bisq 1)".

Not labelled: MaxTradeSizeUnsigned (.002 BTC) and MinTradeSizeToBeSigned (.0005), which the note does not cover; .002 BTC matches the pinned code's small-trade amount and note bisq1-dynamic-limits. MaxBisqEasyTrade (Bisq 2) is also unchanged.

Why not per-article wording

  • The article sources hold no number to correct, only the macro call. A wording change would mean adding text next to 28 placements in 23 articles, several of which are still one-line sources needing a formatting commit first.
  • Editing the template renderings would break their hash receipts and misrepresent what the archive contains.
  • The note does not say 0.0624 BTC is wrong, only that it is not universal. Under the pinned code, if the DAO parameter is at or above the 0.25 BTC clamp, the risk-factor formula gives 0.0624 BTC for the highest-risk methods (factor 4), 0.0832 (3), 0.1252 (2) and 0.25 BTC (1); Bisq's own TradeLimitsTest asserts these values. NEFT, UPI, PayTM, Bizum and Tikkie scale their own limits instead (at the cap 0.0025, 0.00625, 0.00625, 0.005 and 0.00625 BTC), and account signing and age can lower the allowance for buyers using chargeback-risk methods. This is arithmetic from the code; the live DAO parameter was not looked up. So the label says "check the limit shown in Bisq 1" rather than "not a valid limit". Bisq enforces the limit when an offer is created, so a reader cannot exceed it by following the page.

Sources

At Bisq commit ea9d5dff90c99ac462f2b0a7bf9ef92683956619 (tag v1.10.11):

What was checked and what was not

  • Checked: the source lines above; all 28 placements render the label (test in scripts/archived-templates.test.mjs, which fails if the label or the altcoin mapping is removed); the 23 labelled pages match the note's source_slugs exactly; no label lands inside a link, heading or code element. Pages that show any migration note differ from main by the new section ids; the 23 labelled pages also by the label and the extended note.
  • Not done: nothing was run in the Bisq application, no offer was created, and the live DAO parameter value was not checked.
  • Possibly worth a separate look: the "2026 source" superscript names the archive capture date, not the January 2025 template revision; the 0.50 BTC altcoin value is above the 0.25 BTC cap (the note mentions the clamp); Zelle's hard-coded "limited to 0.01 BTC" for unsigned trades is not a macro and is not labelled, while the pinned code gives 0.002 BTC.

Overlap

No article files change, so there is no textual overlap with #56, #57, #59, #60, #62, #63, #64 or #67. #56, #60, #62, #63, #64 and #67 edit other lines in some of the same articles; #57 and #59 change hard-coded numbers in Account limits and Payment methods, which are not macros and are not labelled here.

Expected check results

No wording or receipt changes, so the restoration gate passes: npm test 38/38, and DOCS_SITE=https://hiciefte.github.io DOCS_BASE=/bisq-docs/ npm run build passes ("Source fidelity passed: 209 original bodies/titles/raw sources…", "Checked 601 HTML pages…").

claude and others added 2 commits November 10, 2026 09:22
The 0.0624 BTC and 0.50 BTC values on 23 articles come from the archived
MaxTradeSizeBisq1 and MaxTradeSizeAltcoin templates, expanded at build
time; the article sources contain only the macro calls. Keep the archived
values and add a short label at render time that links to the page's
existing migration note, so no article wording or template receipt
changes.

Sources: Bisq 1 v1.10.11 TradeLimits.java L40-L88 (0.25 BTC clamp, DAO
parameter) and PaymentMethod.java L395-L431 (risk-factor calculation),
commit ea9d5dff.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TcbFo7FxLxPktLKLFLLxae
The label now says "check the limit shown in Bisq 1", and the note names
where: the payment account's Limitations field, and the create-offer
amount check. Tikkie scales its own default (0.05 BTC times the clamped
DAO parameter over 2 BTC), so under v1.10.11 it is at most 0.00625 BTC
and the 0.0624 BTC on its page never applies; the note says so and cites
the default.
@coderabbitai

coderabbitai Bot commented Nov 10, 2026

Copy link
Copy Markdown

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 59 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration

  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: defaults
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: ae946a4a-897b-4440-a337-2382c164a8d8
Commits

Reviewing files that changed from the base of the PR and between 574168b and 155cffb.

Files selected for processing: 4

  • migration/source-review-notes.json
  • scripts/archived-templates.test.mjs
  • scripts/lib/archived-templates.mjs
  • src/components/SourceHistory.astro
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

Share

@hiciefte

Copy link
Copy Markdown
Collaborator Author

Automated note: moved to #98, opened from a fork with the same changes and corrected commit authorship. Please continue the review there.

@hiciefte hiciefte closed this Nov 10, 2026
@hiciefte
hiciefte deleted the content/historical-trade-limit-macros branch November 10, 2026 10:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants