SAIL.r Exclusive Access

SAIL.r Phase 1 — Operational & Custody Framework

Executive Summary

Amy and Liquid Royalty are launching an initial structure for providing discounted SAIL.r access through Amy.

1. Operating Map, Wallet Addresses & Responsibilities

This section identifies the signer wallets, Safe wallets, asset flows, and operating responsibilities for the SAIL.r structure.

The purpose is to make clear, from the start:

who the signers are

which wallet each signer uses

which two Safe wallets hold assets

where user USDe deposits go

where SAIL.r inventory and rewards sit

how rewards, settlement, and maturity delivery are executed

1.1 Wallet & Safe Address Register

1.2 Signer Responsibilities

The Berachain representative is not expected to manage Amy's frontend, users, ledger, reward calculations, or day-to-day operations.

No single signer can move assets alone.

1.3 Wallet Purpose Matrix

This separation prevents user deposit USDe from being mixed with SAIL.r-generated reward USDe.

1.4 User Deposit & Allocation Flow

1.5 Weekly USDe Reward Flow

No Amy reward wallet is used in the standard weekly reward flow.

1.6 Maturity Delivery Flow

At maturity, the user receives their SAIL.r principal directly. There is no automatic swap back to USDe and Amy does not manage exit liquidity.

2. Product Model

2.1 Discounted Access

Amy provides eligible users access to a SAIL.r allocation at an 18% discount off the live market price.

The 2% difference between the Liquid Royalty discount and the user discount is Amy's operational revenue from the SAIL.r product.

2.2 Lock Period

Each confirmed user allocation carries a fixed 6-month lock from the payment confirmation date. During the lock period, users earn weekly USDe rewards based on their confirmed SAIL.r allocation size and active earning days held. The user's earning period begins at 00:00 UTC on the day following payment confirmation.

2.3 Delivery at Maturity

At lock expiry, the user's SAIL.r principal is delivered directly from the SAIL.r Inventory & Rewards Safe to their wallet. There is no automatic swap back to USDe. Amy does not manage exit liquidity. Once delivered, the user holds the SAIL.r as a permanent position.

3. Asset Classification

3.1 Allocated Inventory

SAIL.r tied to confirmed user positions.

Reserved for users

Cannot be withdrawn

Remains locked until maturity delivery

Once a user position is confirmed, the corresponding SAIL.r is treated as committed inventory.

3.2 Unallocated Inventory

SAIL.r not tied to confirmed user positions.

Remains under Liquid Royalty ownership

May be withdrawn through multisig approval

May continue generating operational reward yield while idle

4. Inventory Procedures

4.1 Initial Allocation

Liquid Royalty will provide an initial funded inventory allocation of approximately 1,000 SAIL.r.

Additional SAIL.r inventory is not automatically required from Liquid Royalty. Any inventory top-up beyond the initial allocation may only be added where demand requires it and both Amy and Liquid Royalty agree.

4.2 Inventory Review

Unallocated inventory may be reviewed periodically. If inventory remains substantially unused after 90 days, Liquid Royalty may request withdrawal of some or all unallocated inventory through 2-of-3 multisig approval.

5. Deposit Flow & Validation

5.1 Deposit Flow

User qualifies (Gold or Platinum tier)

User enters a USDe amount

Amy fetches the live SAIL.r price

The 18% discount is applied and a quote is generated

User confirms the deposit directly from their wallet (approve + confirm)

USDe is sent directly to the User Deposit Safe.

5.2 Quote Expiry

Quote is valid for 120 seconds

If the transaction is submitted before expiry, it is accepted

If the wallet flow begins before expiry but the transaction lands shortly after, a 30-second grace window applies

If outside both the expiry and grace window, the transaction is marked as failed/expired and the user must request a new quote

5.3 Validation Rules

Only USDe deposits are accepted and validated

Wrong token or wrong destination transactions must not auto-confirm

Quote expiry is enforced backend-side, not only in the UI

The following fields are populated in the operational ledger for every transaction: quote_expires_at, tx_submitted_at, validation_status, and late_flag

Failed, invalid, or mismatched transactions are handled cleanly and flagged in the ledger

5.4 Deposit Confirmation

No intermediate holding wallet is used. User deposits route directly to the User Deposit Safe. Any deposit contract or frontend transaction layer exists only for routing and validation - it does not hold user funds.

6. Reward Procedures

6.1 Reward Source

SAIL.r inventory held inside the SAIL.r Inventory & Rewards Safe generates reward inflows in USDe.

6.2 Earning Start Rule (UTC Cutoff)

A user's earning period begins at 00:00 UTC on the day following payment confirmation.

The deposit day (10th May) earns no rewards

This rule applies regardless of deposit time within a given day. The cutoff is always midnight UTC after the confirmation date.

6.3 Distribution

Rewards are calculated per position, based on allocation size and active days held. Rewards are distributed weekly in USDe. Amy prepares a weekly Safe payout batch from the SAIL.r Inventory & Rewards Safe directly to eligible user wallets. The payout batch requires 2-of-3 multisig approval before execution. Payout transaction hashes are recorded in the operational allocation ledger.

6.4 Unallocated Inventory Rewards

Rewards generated from unallocated SAIL.r inventory are retained operationally by Amy.

idle inventory to remain productive while awaiting future allocation demand

Amy to offset operational costs associated with running the SAIL.r access system

As user allocations increase, the proportion of rewards retained operationally by Amy decreases accordingly, as rewards attributable to allocated positions are distributed to users weekly in USDe.

6.5 Reward Transparency

The SAIL.r Inventory & Rewards Safe address will be publicly shared for transparency around reward inflows and weekly reward distribution flows. Weekly payout transactions will be recorded in the operational ledger.

7. Settlement Procedures

7.1 Settlement Cadence

Settlement to Liquid Royalty occurs monthly through coordinated settlement batches.

7.2 Settlement Calculation

Settlement amounts are based on:

Confirmed allocated positions

Reconciled against the operational ledger

7.3 Settlement Execution

Amy prepares the monthly settlement calculation from confirmed allocated positions in the operational ledger. Liquid Royalty reviews the settlement calculation before approval. Settlement is paid from the User Deposit Safe to the Liquid Royalty settlement wallet and requires 2-of-3 multisig approval before execution. Liquid Royalty approval is given by signing the Safe transaction.

7.4 Gas Costs

Amy is responsible for routine operational gas costs associated with preparing and executing standard SAIL.r transactions, including weekly reward batches, monthly settlement batches, and maturity delivery batches. Gas costs are expected to be minimal on Berachain and are treated as part of Amy's operational responsibility.

8. Maturity Delivery

8.1 Delivery Trigger

At lock expiry, users become eligible to receive their allocated SAIL.r principal.

8.2 Processing

Amy will process maturity deliveries in coordinated operational batches where practical. Deliveries should occur within a reasonable operational window following maturity, without unnecessary delay solely for batching efficiency.

8.3 Execution

Maturity delivery transactions originate from the SAIL.r Inventory & Rewards Safe and require 2-of-3 multisig approval before execution.

9. Signer Responsibilities

Signer responsibilities are summarised in Section 1.2. In short, Amy prepares operational activity, Liquid Royalty provides inventory and reviews LR-related movements, and the Berachain representative acts as a neutral third-party signer for custody security and continuity. No single signer can move assets from either Safe alone.

10. Continuity & Failure Handling

10.1 Signer Unavailability

If one signer becomes temporarily unavailable, the remaining two signers may continue required operations.

10.2 Dispute Protection

If operational disputes occur, no single party may move funds unilaterally. The 2-of-3 structure ensures shared control.

10.3 Amy Unavailability

If Amy becomes unavailable, Liquid Royalty and the Berachain representative retain the ability to coordinate:

Inventory recovery

User maturity resolution

Operational continuity decisions

10.4 Liquid Royalty Unavailability

If Liquid Royalty becomes unavailable:

Allocated user positions remain fully tracked through the operational ledger

Custody remains protected through multisig controls

This structure is designed to reduce dependency on any single operator.

11. Transparency & Tracking

11.1 Operational Ledger

Amy maintains an internal operational allocation ledger tracking:

Quote IDs

Deposits

Wallet addresses

Allocation amounts

Timestamps (quote_expires_at, tx_submitted_at)

Validation status (validation_status, late_flag)

Maturity windows

Transaction hashes

11.2 Public Transparency

User-facing transparency will include:

User Deposit Safe address

SAIL.r Inventory & Rewards Safe address

Public explanation of custody structure, allocation model, reward flow, settlement flow, and maturity delivery process

User-specific position visibility inside the Exclusive Access page, showing only the connected user's own active positions

11.3 Reconciliation

Operational tracking is reconciled against:

Onchain transactions

Safe balances

Reward distributions

12. Key Confirmations

• Two-Safe multisig structure: Deployed

• Liquid Royalty signer wallet: Confirmed

• User Deposit Safe address: Confirmed

• SAIL.r Inventory & Rewards Safe address: Confirmed

• Liquid Royalty settlement wallet: Confirmed

• Initial inventory allocation: Approximately 1,000 SAIL.r agreed

• Allocated inventory backing: Allocated user positions must remain fully backed

• Monthly settlement cadence: Agreed

• Weekly reward distribution: Agreed

• 120-second quote expiry with 30-second grace window: Confirmed

• USDe-only deposit validation: Confirmed

• UTC next-day earning rule: Confirmed

• Additional inventory top-ups: Not automatic; any top-up beyond the initial allocation requires agreement between Amy and Liquid Royalty

• Liquid Royalty settlement approval: Given by signing the monthly Safe settlement transaction

References

This framework forms the operational basis for the SAIL.r rollout through Amy. Additional public documentation may later be published through Amy explaining custody, reward flows, maturity delivery, and allocation mechanics for end users.