feat(sub-second): add how to adopt sub-second finality page#1987
feat(sub-second): add how to adopt sub-second finality page#1987
Conversation
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Thanks for the thorough work on ecosystem/subsecond.mdx; I’ve left several suggestions to align wording, formatting, and safety guidance with the docs conventions, so please apply the inline suggestions where they fit. Once updated, the document should read more consistently and be clearer for both UX and infrastructure readers.
ecosystem/subsecond.mdx
Outdated
| Testnet operates close to the target speed (200–400ms block finality) and is the primary environment for testing. | ||
|
|
||
| ## Wallets and apps | ||
|
|
||
| A faster chain alone does not improve user experience if the application continues to use HTTP polling. In this case, users will still observe delays of 10+ seconds. To support sub-second UX, transaction updates must be delivered in real time. |
There was a problem hiding this comment.
[HIGH] Reader-directed “users will still observe delays”
The paragraph under “Wallets and apps” states, “In this case, users will still observe delays of 10+ seconds.” This phrasing addresses the audience indirectly as “users” and describes what they “will” observe, which conflicts with the style guide’s requirement to avoid reader-directed or personal framing. The surrounding content is otherwise factual, so keeping this sentence as-is breaks tone consistency in an important UX guidance section.
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
ecosystem/subsecond.mdx
Outdated
|
|
||
| ### API token | ||
|
|
||
| - For testing purposes any valid token for TON Center allows for 2 concurrent streaming connection. |
There was a problem hiding this comment.
[HIGH] Millisecond spacing inconsistency in latency bullet
Within the “TON Center Streaming API v2 provides” bullet list, the latency bullet uses 30–100ms without a space before ms. Elsewhere in the document, milliseconds are written with a space (for example, 30–100 ms). The numeric formatting guidance calls for consistent spacing before units, and diverging from that in a concise bullet about latency makes the line visually inconsistent with other timing references.
| ### API token | |
| - For testing purposes any valid token for TON Center allows for 2 concurrent streaming connection. |
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
|
|
||
| All self-hosted components must be updated to versions that support Catchain 2.0. | ||
|
|
||
| - TON node and liteserver – update to the latest release before mainnet activation. |
There was a problem hiding this comment.
[HIGH] Vague “latest release” requirement for node version
The bullet “TON node and liteserver – update to the latest release before mainnet activation.” uses the vague phrase “latest release” for a required component version. The style guide forbids unversioned requirements like “latest” because they are not reproducible and make it unclear which versions are known to be compatible. This reduces reliability for operators trying to match the documented configuration.
| - TON node and liteserver – update to the latest release before mainnet activation. |
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
This comment has been minimized.
This comment has been minimized.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
|
|
||
| 1. Connect to testnet endpoints. | ||
| 1. Initiate a TON transfer. | ||
| 1. Observe all four statuses in sequence: `"pending"` → `"confirmed"` → `"finalized"`. |
There was a problem hiding this comment.
Good catch — I'll apply the edits now if you and @aigerimu don't mind :)
UPD: After conversing with Aigerim, it's now clear that the page itself will be rewritten. As such, all suggestions should be kept in mind and applied only to the rewritten page, which is to be made by Aigerim. Ping me if any further help is needed.
novusnota
left a comment
There was a problem hiding this comment.
It's ok to say that, as of now, tangible changes are being made only to the testnet. Yet this page should focus on instructing dApp and wallet devs on how to, well, adopt sub-second finality in their projects. Like, a) what's the status and expected outcome, and b) how to adapt to the changes, with steps or checklists to follow.
All lower-level details, even the name of the consensus protocol (Simplex aka "Catchain 2.0"), should be left to pages within "Blockchain foundations": see #1991 and so on.
@aigerimu @thekiba Let's keep that in mind when rewriting this page, wdyt? :)
closes #1983