ck CommonKitNEAR TESTNET

SOCIAL MONEY / THE JUDGE'S TOUR

Shared gear.
Accountable money.

One community camera. Two possible returns.
Follow the money in 60 seconds.Vercel + Meteor · 9–12 November · no wallet needed

01 / A LIBRARY OWNED BY ITS COMMUNITY

Borrow the camera.
Keep the trust.

A campus club lends its camera. Who collected it? Did it come back damaged? Who gets the bond? The borrower, custodian and council each have a distinct job.

Read both recorded outcomes ↗
CAMPUS CAMERA KIT / 001Illustrative camera kit; not evidence of physical condition
B BorrowerC Custodian2/2 Council

02 / MOBILE REVIEW · BOOKING #13

A bond with
clear boundaries.

Booking #13 began with a 390 × 844 Chrome review on Vercel and a real Meteor approval. Its finalized reservation is publicly verifiable. The next chapters follow completed bookings #10 and #11.

Mobile-width review and signature initiation; later confirmation at desktop width. No physical phone test.

ATTACHED DEPOSIT · TESTNET NEAR0.111
0.011 principal0.010 refundable bond + 0.001 usage fee
0.100 storageRetained separately; outside the principal ledger
390 × 844 reviewInspect the screenshot & live receipt ↗

03 / NORMAL RETURN · BOOKING #10

All good.
Full bond back.

The custodian accepts the return with zero damage. The borrower withdraws the full bond. Two votes on treasury #15 pay the usage fee back to the community, where the DAO can decide how to use it.

Check the 8 normal-return transactions ↗
RECORDED ALLOCATION · NEAR
0.011 principal
Borrower0.010Full bond returned
Community DAO0.001Usage fee withdrawn

Booking closed · 8 recorded transactions

04 / DISPUTE · BOOKING #11, PROPOSAL #16

One vote.
Money stays put.

The custodian reports damage. A council member proposes a 0.003 NEAR deduction. The first approval cannot release escrow: the policy requires both council accounts.

Read the dispute case file ↗

Saved one-vote checkpoint ↗

HISTORICAL CHECKPOINT / NOT LIVE STATUS
1/2approvals required
✓Council 2Approved
·Council 1Awaiting vote
Still in escrow0.011 NEAR

Booking disputed · proposal pending · zero credits

05 / SECOND APPROVAL → DAO EXECUTION

Two votes.
A recorded decision.

The second approval lets Sputnik call the library contract. Proposal #16 creates credits; treasury #17 and the borrower’s withdrawal actually move the funds. The verifier checks child receipts, too.

Check the 11 dispute transactions ↗
RECORDED ALLOCATION · NEAR
✓ Council 2 + ✓ Council 1
0.011 principal
Borrower0.007Bond less damage
Community DAO0.0040.003 damage + 0.001 fee

Credits → separate withdrawals → final receipts

06 / DON'T TAKE OUR WORD FOR IT

Two paths.
Verify every step.

Verify both completed flows and the separate mobile reservation. Fresh public reads check bookings, proposal votes, final receipts and the accounting invariant.

Read the recorded proof ↗

Then run fresh public checks ↗

No login or wallet. Recorded proof stays readable during RPC outages; it is not a fresh PASS.

CHECKS AVAILABLE / NOT A LIVE PASS COUNT
Normal returnBooking #10 · 8 transactions
21 ↗
DAO disputeBooking #11 · 11 transactions
27 ↗
Mobile reservationBooking #13 · 1 transaction · reservation only
6 ↗
Deposited principal= escrow + credits + pending + withdrawn

Fresh results appear only on the verification page. Later demos can change whole-library totals.

Illustrated replay of recorded evidence, not a live transaction or real-time execution. Choose Play to begin, or read each chapter below.

WHAT THIS PROVES

Working contracts.
Visible limits.

The two completed flows contain 19 real NEAR testnet transactions. Booking #13 adds a separate mobile-initiated reservation from the public Vercel demo. The owner approved Meteor prompts. One operator controls the demo's two council accounts. Evidence fixtures are synthetic; a hash does not prove physical condition. The prototype is not audited.

Watch or download the 1:55 film ↗Read both recorded outcomes ↗Rehearsal provenance ↗Run a new wallet demo ↗Normal-return manifest ↗Dispute manifest ↗