Apply the preparation and wallet boundary.
For latest-news questions, use host public-read tools to check relevant original posts from the official account and developer @0xbeans. Attribute proposals, announcements and observed deployment separately; publication and retrieval times differ. State incomplete coverage rather than treating the dated context below as fresh status. Explanation-only questions need no gratuitous refresh.
Current onchain questions favor authenticated contract reads, not social announcements. Auctions covers round/cap-window and order distinctions; history covers finite, generation-aware research. Inspection distinguishes issuance, ledger balances, burns and active restrictions without a fixed helper or deployment catalog.
Use documents for published rules, contracts for identities, and inspection to interpret freshly requested observations. Unavailable state remains unknown. User-requested monitoring, schedules and external evidence caches follow safety; do not start unsolicited background activity or silently update installed sources during research.
The separately authenticated S-Bill deployment and selected frontend ABI replace the September27 preview-only knowledge boundary. Use the canonical S-Bill guide for rate/amount quotes, positions, maturity cohorts and exit/redemption/roll questions; dated provenance records identity and evidence scope, not saved live defaults. The reviewed transactional frontend uses manual roll, conflicting with older auto-roll About copy.
Security reviews are completed per user-reported developer confirmation. Public report/reviewer/revision/deployment mapping remains a separate unknown; do not repeat the older planned-audit announcement as current status or imply review has not occurred. No whole-site/timeline synchronization, verified Solidity correspondence or safety guarantee follows.
The fresh 2026-09-27 check reviewed all sixteen whitepaper HTML sections and selected explanation/preview logic in six current app-linked components: Whitepaper, ChartersGuide, LiveProtocol, ManifestoPage, StakingAbout and StakePage. Seven page bodies, the mount bundle and those components were retrieved completely as data, not executed. The reconciliation record (sr-source-reconciliation-2026-09-27) records exact URLs, byte counts and SHA-256 fingerprints.
Social coverage is known-post refresh, not a latest timeline sweep: the official Second Mandate, v1.1, S-Bill and v1.2 roots, the official check-in reply, and the developer proposal root plus four proposal/deployment replies were re-read. Mirror timestamps are publication-time attribution, separate from retrieval. Both account timelines returned 429; canonical reader paths were blocked and alternative developer mirror leads returned 403. No contiguous timeline interval was reviewed, including newer posts after the September26 review through September27. Nothing here establishes that no newer announcement exists or that all sources are synchronized.
The substantive explanation change is that the charter guide now says 12-hour charter auctions; the whitepaper retains conflicting daily/24-hour, initial-zero and no-bids wording. The S-Bill preview remains dated sample evidence, and the Second Mandate remains strategy rather than a newly authenticated contract family. No live balances, rates or deployed economics were installed.
The official v1.2 post, freshly retrieved on 2026-09-27 via a public Nitter mirror, announces:
- Limit orders for branch auctions: bids at the user's desired auction price, an open orderbook, and FCFS best-attempt keeper execution. This is not guaranteed fill, price, timing, reserved inventory or independently verified onchain ordering. A limit/bid is not a settled purchase.
- Charter auctions begin: one charter at the branch-auction cadence, the first opening at 5.5 ETH, then 3× clearing price for subsequent openings. Treat 5.5 ETH as the announced initial opening, not today's price, a reserve floor or an executable quote. Current cadence and availability need authenticated live reads.
- Security review reported: “All changes have gone through a security review.” No independently retrieved report, reviewer, exact revision/scope or deployment correspondence is established by that statement.
Remaining conflict with public design text: the freshly read whitepaper §§6–8 and current component still contain daily/24-hour charter wording, an initial zero allocation and blanket “no bids or escrow” immediate purchases. The September27 charter guide now says each charter auction runs 12 hours, unlike its September26 daily wording. Preserve the older whitepaper design as provenance, not current v1.2 policy. The announcement supersedes cadence/allocation and order entry; neither it nor the updated guide independently verifies implementation, an unsold-round fallback, funding/escrow/cancellation/refund mechanics, or removal of every direct Dutch-purchase path.
The 2026-09-26 interface review placed order views on the license auction itself; refresh identity and semantics before current reads. Global count is not “my orders,” and page IDs do not establish charter ownership. Incomplete enumeration is unknown, not zero orders; limits and fillability are not settled cost or guaranteed execution.
Provenance: sr-protocol-v1-2-announcement, sr-v1-2-deployment-evidence and sr-v1-2-read-interface; auctions and contracts distinguish policy from authenticated interfaces and independently corroborated creation. The fresh mirror attributes September26, 23:32 UTC to the post; the earlier review exposed only relative time. This is mirror evidence, not direct X verification. Publisher activation metadata is distinct from creation or independently proven Registry cutover. Review dates and “is here” are not transaction-success evidence. S-Bill readiness or audit coverage is not established by this release.
The official v1.1 post, reviewed on 2026-09-22, says the changes go live that day and identifies three changes:
- Historically announced two 12-hour license auctions, 50 branches each, with the three-per-charter limit remaining per 24 hours. The 50-branch figure is not a current v1.2 allocation; use fresh per-round supply/cap/remaining getters without overriding them from this announcement. A round is not the charter cap window. The whitepaper §§7–8, freshly reviewed on 2026-09-25, describes fixed 24-hour purchase windows anchored at activation; deployed reset arithmetic and rounding remain source-unverified.
- Two-hour auction half-life, in the license-auction v1.1 context. The refreshed whitepaper gives the gap-to-floor curve
P(t) = floor + (start − floor) × 2^(−t/2h); this is published design, not authenticated deployed arithmetic. Its separate four-hour charter half-life is unverified for v1.2; its retained 24-hour charter clock is superseded by the v1.2 branch-matched cadence announcement above. - Bid-side-only incremental POL: buy tokens from the market and send them to the new protocol-owned Incentives Vault, rather than pair them into additional two-sided liquidity. Retained tokens are not burns or holder entitlements.
These are official announced changes, no longer merely the earlier developer proposal. The announcement does not confirm that proposal's 50/50 branch-auction burn/incentive split, team-allocation restrictions or eventual unused-incentive burn. It reports a security review; no independently reviewed report, reviewer, scope or deployment correspondence is established. Do not translate “reviewed” into a safety guarantee.
The dated deployment sources distinguish publisher identities from historical creation/cutover. They record a Genesis Liquidity Manager role separate from POL Buyback and Incentives Vault; neither a registry event nor frontend name fixes present routing. Discover all relevant generations for historical questions. Keep retained POL acquisitions distinct from Contraction Vault burns, with authenticated asset units and receipt attribution.
The official reply announced a forthcoming free website check-in button. A later source-text review on 2026-09-25 found Check in now and a checkIn action in the published frontend bundle (sr-owner-check-in-frontend). That establishes frontend implementation provenance, not introduction time, a currently enabled rendered flow or transaction success: the wallet path was not exercised. Refresh the UI when answering current availability. Zero protocol charge does not promise zero gas. Exits retains the existing inactivity rules.
Provenance: sr-protocol-v1-1-announcement, sr-v1-1-deployment-evidence, sr-v1-1-read-interface, sr-pol-buyback-event-interface and sr-protocol-control-dependencies. No review RPC snapshots are installed as runtime state or a fallback.
The official S-Bill announcement, freshly retrieved on September27 with a mirror-attributed publication time of September23, 21:46 UTC, calls the product non-dilutive variable-APR staking and says “Contracts are going into security audits this week.” This is planned-audit provenance, not a completed audit, launch proof or current verdict. Older protocol audits do not establish S-Bill coverage. sr-sbill-announcement
The official staking explanation describes STANDARD deposits earning buyback-funded premiums, with a zero-dilution claim. The September27 staking component had fixed sample bills and an aria-hidden, inert Coming soon preview. The explanation component reviewed then retained simulated rates and conflicting “accepting deposits”/“S-Bills Coming Soon” copy. These are historical September25–27 observations, not a standing status verdict. No rendered deposit flow or wallet transaction was exercised by that review. sr-staking-preview
Historical published design, not current enforced terms: users name a rate; a term begins when the bid fills; at maturity the bill auto-rolls or is redeemed. Early voiding is described as returning principal less an exit fee, with half the fee burned and half distributed to stayers, while the current-term premium is forfeited to remaining locked bills. The page describes buybacks topping up the premium budget each epoch and premium escrow at deposit. Its illustrated 15-day term and 5% exit fee are not canonical deployed parameters. The current-vs-historical guide records the transactional frontend's manual-roll conflict; do not turn this old copy into current execution rules.
That reconciliation did not authenticate an S-Bill deployment/read ABI or demonstrate a real position read. Its complete-body retrieval removed an earlier retrieval gap, not every implementation or timeline gap. Preserve that source truth as historical; the October2 evidence now establishes a separate deployed role and usable selected frontend interface. Neither an auction announcement nor a sample UI supplied that proof.
Current questions follow S-Bills, not this preview. Failed current reads leave the affected values unknown; they do not undo authenticated deployment evidence or revive “Coming soon.” Do not substitute sample bills, simulated rates or dated state. Read-only inspection does not require a public audit report as a blanket prerequisite; disclose report correspondence separately from the developer-confirmed completion status.
The official announcement introduces a second mandate to drive liquidity flows, powered by STANDARD. The manifesto, reviewed in full on September20 and reconciled against its current linked component on September27, describes an open, transparent liquidity engine for tokenized stocks, not another stock issuer. This extends the project's documented monetary-policy focus toward market liquidity: announced direction, not evidence of deployed mechanics. [sr-second-mandate-announcement; sr-second-mandate-manifesto]
The intended loop is to create or approve markets, seed liquidity, coordinate external capital, and return trading fees to the Reserve to fund more markets. That reserve-level reinvestment thesis does not establish a token-holder or charter-holder revenue entitlement, an enforceable distribution, or an executable investment product.
Market rationale, not current observations: the manifesto's “Mind the Gap” section uses September 17 SPY/NVDA/MSFT USDG-side balances to illustrate thin liquidity, and an August 30 HIMS squeeze against the prior Friday's stock close to illustrate price dislocation. These are dated publisher examples, not independently verified market data, current depth, or executable prices. They may be quoted numerically with attribution and dates or used as labeled scenario inputs; fresh market questions require fresh evidence.
The “RESERVE POSITIONS (SAMPLE)” panel is explicitly illustrative. Its funded-market rows, pool shares, APY boost, fees-returned figures, AAPL funding request and ETH-return total are not actual deployments, observed holdings, realized returns, a live funding request or a yield offer. The separate “as of today” reserve graphic uses fixed values in the reviewed publisher component; neither that label nor fetching the page afresh makes it a live or block-scoped reserve observation. Obtain independently grounded fresh evidence for current reserves; historical or sample figures may be retained with their provenance, never substituted for unavailable current state.
Neither the announcement nor the manifesto establishes new Second Mandate contract names, addresses, ABIs, deployment correspondence, custody controls or enforceable fee-distribution rights. Market creation/approval, external-capital coordination and fee return name intended functions, not published contract interfaces. They do not require us to invent a factory, vault or router; existing modules could be involved, but the implementation choice is not established. The whitepaper remains the source for documented monetary mechanics and reserve routing.
The Second Mandate is distinct from both the earlier developer proposal and the later official v1.1 changes. The strategy announcement itself did not confirm auction cadence or proceeds routing; v1.1 supplies the separate confirmation and limits above. Requested quantitative analysis may model liquidity returns, external-capital flows or holder-income scenarios under explicit assumptions. Neither announcement nor sample figures establish those outcomes or a holder entitlement; separate illustrative inputs from observations under modeling boundaries.
Source provenance records sr-second-mandate-announcement and sr-second-mandate-manifesto. The September27 public-mirror refresh attributes September20, 15:52 UTC to the announcement, supplementing the earlier relative-time-only review; this is not direct X verification. Manifesto retrieval/review dates do not establish publication time.
The earlier @0xbeans thread remains historical provenance (sr-beans-auction-burn-pol-proposal), not a competing catalog of current rules. The official v1.1 announcement supersedes proposal status for license cadence, faster half-life and bid-side POL. Its acquired tokens go to the Incentives Vault; do not retain the proposal's old POL-vault destination as current policy.
The proposed 50/50 immediate-burn/incentive-vault split of branch payments, team restrictions and eventual burning of unused incentives are not confirmed by that announcement. They remain unverified proposal elements, not half-price licenses, already distributed rewards, verified ledger settlement, enforceable controls or a promise that retained tokens have burned. The proposal described the separate Contraction Vault buyback-burn mechanism as unchanged.
The earlier relative deployment/security-review estimate is historical context, not a pending deployment verdict after the official release announcement and separately corroborated cutover. Conversely, the official statement that a security review occurred is not independently checked audit coverage. Current state still requires live reads, and complete new-module source/ABI and privilege questions remain bounded by the source limits.
Use the scoped canonical parameters, auctions and reserves: v1.1 reference values supersede the relevant license/POL proposal descriptions; v1.2 separately changes announced charter cadence and adds branch limit orders. Neither announcement silently changes the ongoing ETH split or exit fees. Conditional scenarios may explore unconfirmed elements only as explicit assumptions.