A full cycle, with numbers

A worked example following one user's position from lock to claim. All addresses fictional; all numbers exact.

The setup

• Alice holds 10 DIEM and wants to lock until August 1, 2026.
• Today is June 17, 2026, 14:30 UTC.
• Days from now to maturity: 44 (floor of 44 days 9.5 hours).

She picks the PT20 path so her principal will be tradeable on a DEX.

Step 1 — Lock

Alice approves Locker for 10 DIEM, then:

locker.lockPT20(
  10n * 10n ** 18n,           // amount: 10 DIEM (wei)
  1_785_542_400n,             // maturity: 2026-08-01 00:00 UTC
  alice.address                // recipient
);

What happens under the hood:

1. 10 DIEM moves to the Vault, then Vault.stake(10) runs — Venice now sees the vault's stake increase by 10 DIEM. The protocol's inference capacity for tomorrow goes up by 10 × $1 = $10.

2. DD minted to Alice. From Jun 17 14:30 UTC to Aug 1 00:00 UTC is 44 days 9.5 hours = 3,835,800 seconds. The DDMinter formula floors that to floor(3_835_800 / 86_400) = 44 days, so Alice receives 10 × 44 = 440 DD.

3. PT20 deployed (if new) and 10 PT20 minted. Since this is the Aug 2026 PT20, the deterministic address might be e.g. 0x…AUG. Alice now holds 10 kDIEM-AUG2026.

Alice's wallet after step 1

DIEM:                   ~0  (her 10 moved into the vault)
DD:                   440
kDIEM-AUG2026:              10

Step 2 — Decide what to do with DD and PT20

Alice has options. We'll follow three subplots to show the full surface:

2a. Sell half her PT20 on a DEX

There's a Uniswap V3 pool kDIEM-AUG2026 / USDC. Mid-market price right now is $0.985 per PT20 (small discount reflecting time-value of waiting 44 days for DIEM at $1).

Alice sells 5 PT20 for $4.925 USDC.

DIEM:           0
DD:           440
kDIEM-AUG2026:       5
USDC:        4.93

2b. Use 100 DD to bid for tomorrow's inference

A few days later, on Jun 22 16:00 UTC, Alice wants to use $100 of Venice inference on Jun 23. The auction is T+1: every bid placed during day D is for inference on day D+1. She calls:

auction.bid(
  vault.address,     // platform (Venice = the vault)
  100n * 10n ** 18n, // ddAmount: 100 DD
  1n * 10n ** 18n    // kaiBid: 1 KAI
);

100 DD + 1 KAI move from her wallet into escrow.

At Jun 23 00:00 UTC, anyone (typically the backend cron) calls settle. Assume:

• Cap that day: 200 DD (matches the vault's total stake).
• 5 bids total, sorted: Bob 3 KAI / 80 DD, Alice 1 KAI / 100 DD, Charlie 0.5 KAI / 50 DD, Dave 0.1 KAI / 200 DD, Erin 0.05 KAI / 30 DD.

Walking the bids:

Rank	Bidder	DD asked	Cumulative	Outcome
1	Bob	80	80	win
2	Alice	100	180	win (180 ≤ 200)
3	Charlie	50	(180+50=230 > 200)	skipped (oversized for remaining 20)
4	Dave	200	(180+200 > 200)	skipped
5	Erin	30	(180+30 > 200)	skipped

Alice wins. Clearing KAI = 1 KAI (her own bid was the lowest winning). Bob and Alice each pay 1 KAI; total 2 KAI burned. Alice's 100 DD is burned.

Alice's overbid KAI: 1 - 1 = 0 KAI (she didn't overbid). No KAI refund. Bob overpaid by 3 - 1 = 2 KAI, he gets that back via claimRefund.

Alice now calls requestKey(vault, day, herBidIndex). The backend issues a Venice API key scoped to $100, which Alice uses on Venice's API between 00:00 and 23:59:59 UTC on June 23.

2c. Hold the rest of PT20 to maturity

Alice still has 5 kDIEM-AUG2026 in her wallet after the half-sale. She plans to redeem at maturity.

Step 3 — Maturity

It's now August 1, 2026, 00:00 UTC. kDIEM-AUG2026 just matured.

Alice approves Redeemer for her 5 PT20, then:

redeemer.redeemAndRequestUnstake(
  pt_aug2026_address, // pt
  5n * 10n ** 18n,    // ptShares
  alice.address       // beneficiary
);

Atomic flow inside the call:

1. Redeemer pulls 5 PT20 from Alice into itself.
2. PT20.redeem(5, redeemer, redeemer) — 5 PT20 burned, the matching internal claim is destroyed.
3. Queue.requestUnstake(5, alice) — request recorded for today (Aug 1, dayId = 20300).

Alice's wallet now:

DIEM:           0  (waiting)
DD:           340  (440 - 100 spent)
kDIEM-AUG2026:       0
USDC:        4.93

The buyer of the other 5 PT20 (whoever holds them on Aug 1) will do the same thing on their own — redemption is permissionless and parallel.

Step 4 — Sync the queue

The backend cron at Aug 2 00:00:30 UTC calls Queue.sync(). The queue:

1. Finds Aug 1 in state Requested with total = 5 DIEM (Alice) + 5 DIEM (other PT20 buyer) = 10 DIEM.
2. Calls Vault.initiateUnstake(10) — Venice records coolDownAmount = 10 DIEM, coolDownEnd = Aug 3 00:00:30 UTC.
3. Aug 1 transitions to state Unstaking.

Step 5 — Drain after Venice cooldown

Backend cron at Aug 3 00:00:30 UTC calls Queue.sync() again:

1. _windowReady() — yes, block.timestamp > coolDownEnd.
2. Vault.claimUnstake() — drains the 10 DIEM bucket from Venice into the Vault's free balance.
3. Aug 1 transitions to state Claimable.

Step 6 — Claim DIEM

Alice (or anyone, on her behalf) calls:

queue.claim(20300n, alice.address);

Which does:

1. Looks up requestedByUser[20300][alice] = 5 DIEM.
2. Marks claimedByUser[20300][alice] = true.
3. Vault.transferOut(alice, 5).

5 DIEM lands in Alice's wallet. Final state:

DIEM:           5  (her half of the original 10)
DD:           340  (340 remaining — she can spend or sell)
kDIEM-AUG2026:       0
USDC:        4.93  (from selling 5 PT20 at $0.985 each)

The other PT20 buyer's 5 DIEM lands in their wallet via the same flow.

Total time from lock to claim

Step	Day	Notes
Lock	Jun 17	Instant
Hold / trade / bid	Jun 17 — Aug 1	44 days; she traded, bid, won inference
Maturity & request	Aug 1	Instant on maturity
Sync 1 (initiate unstake)	Aug 2	~1 day later
Sync 2 (drain)	Aug 3	After Venice cooldown
Claim DIEM	Aug 3+	Whenever Alice (or anyone) calls

Time from maturity to claim: about 48 hours. Most of that is Venice's 1-day cooldown plus the daily sync cycle.

Total economic outcome

Alice locked 10 DIEM for 44 days. In exchange she got:

• 5 DIEM back (the 5 she didn't sell).
• $4.93 USDC from selling 5 PT20 early.
• $100 worth of Venice inference used on June 23.
• 340 DD still tradeable or burnable for more inference later.

The other 5 DIEM didn't come back to her — she sold the claim for $4.93. The buyer of that PT20 collected the DIEM directly via their own redeem.

Net: from her 44-day lock of 10 DIEM, Alice extracted $100 of inference + $4.93 cash + 340 DD of future inference, exited half her position early via the DEX, and got the other half back as DIEM at maturity.

Same scenario with PT721

If Alice had picked lockPT721 instead (e.g. with maturity July 15, an arbitrary date), the flow is identical except:

• She gets back one PT721 with tokenId instead of fungible PT20.
• She can sell it on OpenSea/Blur instead of a DEX.
• At maturity she calls redeemPT721AndRequestUnstake(tokenId, beneficiary).

DD math, queue mechanics, and claim flow are identical.