Locking DIEM

Locking is the single entry point for DIEM holders. One call deposits your DIEM, stakes it on Venice, and returns three things:

1. A principal claim (PT20 or PT721) — your right to get your DIEM back at maturity.
2. DD inference credits — proportional to your lock duration.
3. (Implicit) a stake into the protocol's shared inference capacity.

Two paths

Function	Maturity	You receive
Locker.lockPT20(amount, maturity, recipient)	Must be 1st of a month at 00:00 UTC	PT20 (fungible ERC-20) + DD
Locker.lockPT721(amount, maturity, recipient)	Any timestamp	PT721 (ERC-721) + DD

See PT20 vs PT721 for which to choose.

What happens, step by step

For both paths the protocol does the following (atomic — fails as a whole):

1. SafeERC20.transferFrom(msg.sender → vault, amount)         [you must approve]
2. vault.stake(amount)                                        [Venice stake call]
3. DDMinter.issue(recipient, amount, maturity)
       → DD = amount × floor(secondsToMaturity / 1 day)
         (clamped to minimum 1 day)
       → DD.mint(recipient, DD)
4a. PT20 path:
       pt = PT20Factory.getOrCreate(maturity)
       PT20.deposit(amount, recipient)
       (mints `amount` PT20 to recipient against the staked principal)
4b. PT721 path:
       tokenId = PT721.deposit(amount, maturity, recipient)
       (mints a unique tokenId to recipient against the staked principal)

If any step reverts, the whole transaction reverts and nothing happens.

The internal escrow accounting (an intermediate ERC-20 representing the staked principal) is fully encapsulated by the contracts — you never approve, hold, or transfer it. The technical reference for that token lives in the contracts section.

Constraints

Constraint	Value	Why
Minimum lock amount	0.01 DIEM	Anti-dust spam
Maximum lock horizon	400 days	Bound the maximum DD issuance per position
maturity > block.timestamp	enforced	Can't lock to the past
PT20 path requires monthly	enforced	Liquidity concentration
Locker paused → reverts	optional	Owner kill-switch for emergency

DD math, walked through

Three concrete examples for amount = 10 DIEM:

Lock duration	DD minted	Reasoning
1 hour	10 DD	sub-day → minimum 1 day applied
23 hours, 59 minutes	10 DD	floor(seconds / 86400) = 0 → min 1 day
24 hours exact	10 DD	floor = 1
1 day + 1 second	10 DD	floor = 1
30 days	300 DD	floor = 30
365 days	3,650 DD	floor = 365
400 days	4,000 DD	floor = 400

The floor rounding (with min 1 day) closes a previous design flaw where ceiling rounding allowed users to maximize DD by locking at 23:59:59 just before a day boundary.

What you do with what you got

After lock returns, you hold both DD and a principal token, and you have the same three options as anyone else with these tokens:

• Spend DD on inference through the daily auction.
• Sell PT20 on a DEX or sell PT721 on an NFT marketplace.
• Hold until maturity, then Redeemer.redeem* and Queue.claim to withdraw the DIEM. See Unstake queue.

You can have any number of open locks at the same time, each into different maturities, mixing PT20 and PT721 freely.

Locker rotation

The Locker contract address may rotate (e.g. for a bug fix). Rotation is gated by a 7-day timelock — each downstream contract that the Locker talks to (Vault, kDIEM, DDMinter, PT20Factory, PT721) has its own propose* → wait 7 days → activate* flow.

If you have an open PT20 or PT721 position issued under Locker v1, it remains redeemable through Redeemer regardless of Locker rotation — the Locker is only needed for new mint operations.

See Safety & owner model for the full rotation model.