> For the complete documentation index, see [llms.txt](https://boringity.gitbook.io/wsup-mvp-draft/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://boringity.gitbook.io/wsup-mvp-draft/whatsup.md).
# whatSUP?
whats up homie.
### **1. Introduction**
Let me start by explaining why I got into this in the first place. Between July 2024 and January 2025, I explored the **Move ecosystem** extensively—Sui, Aptos, Starcoin, and of course, **Supra**. I wanted to build something that solved the problem of locked or vested tokens for everyday users, especially in smaller or newer Move ecosystems. People kept asking “Wen TGE?” or “Wen unlock?” and that spelled out a major friction point: tokens locked up and doing nothing, while DeFi opportunities pass them by.
At the same time, I noticed how **Sui** favored intense object-orientation, but might face scaling beyond 100-ish nodes. **Aptos** soared with an account-based approach, but that approach complicated object references and modular ownership. So, I thought: *“Why not harness the best of both worlds using Supra’s framework?”*
**Hence, wSup was born**—a **theoretical Liquid Staking Token (LST)** within Supra to let you keep your assets staked (or in vesting) and still get to do DeFi. The concept is simple: create a 1:1 wrapped token that can move around while the underlying asset remains locked or staked.
## so whats up with wSup?
People in newer ecosystems—like Supra—often have tokens **locked** from 3 to 15 months. Maybe it’s a vesting schedule, or maybe they’re staked in a delegation pool. Either way, they see endless questions:
* **“Wen TGE?”** (Token Generation Event)
* **“When do I finally get my tokens?”**
* **“When can I start using them for liquidity, yield, or bridging?”**
From a purely economic standpoint, locked tokens **hamper** early-stage liquidity, and that can stunt growth in DeFi. Projects might take several months to produce a stable DEX, aggregator, or bridging solution, which can lead to negative price action if new capital and user excitement wane.
I kept seeing how *retail users* (the everyday folks, not just big whales or test validators) **cared more** about having a functional ecosystem than seeing who could “ship first.” So, I thought:
> *“What if we turn those locked tokens into something people can still use in DeFi?”*
Hence the idea of **wrapping** tokens 1:1. Your original tokens stay in vesting or staking, but you get a “wSup” version that’s accepted by the lending or bridging modules. That means you’re not forced to wait months, watch from the sidelines, or **sell** at the first unlock. Instead, you can deposit, borrow, and lend right away—even if your core tokens aren’t fully unlocked.
This solves more than user impatience; it addresses a **core liquidity constraint** in early Move ecosystems.
#### **Account-Based vs. Object-Based**
Here’s where architecture matters. Different Move-based chains have **unique** ways of storing tokens and references:
* **Sui**: Very object-oriented, making it easy to pass assets around like real objects. But as I learned from folks like **Joshua D. Tobken** (founder of Supra), Sui might struggle to scale beyond \~100 nodes if they rely on “fast pay.”
* **Aptos**: Gains in scalability and consensus clarity with an **account** approach, but it’s **harder** to do object references or modular ownership of modules that don’t belong to your account.
* **Supra**: Sits somewhere in the middle, letting me unify an aggregator-based approach (like Aptos) but also reference modules in a more object-friendly manner (like Sui).
I remember specifically that Joshua said something like:
> *“Sui has interesting differences, but might not scale. That’s why most other Move chains focus on an Aptos-style approach.”*
That conversation got me thinking:
* Could I build something that **adopts** the flexibility of object references from Sui, but **maintains** an account-based approach for robust consensus and ownership?
* Could I do this on Supra, which already merges aggregator tables and typed references?
So, there I was—**working solo morning to night**—trying to piece together a protocol that would unify locked tokens with real DeFi utility. I confess: I was **building the contracts incorrectly** at first. A huge shout-out to **Nolan & Jatin** for spotting this; they basically said, *“We haven’t added that yet,”* or, *“You’re mixing these aggregator references the wrong way.”* That’s when I realized I had to go back and **tear down** part of my initial design.
#### **3.1 Failed Experiments**
1. **Wrapping System with Taos**\
I tried making a wrapper with some Taos-based approach—only to discover it wasn’t recognized by the aggregator or fungible asset modules we had.
2. **Aggregator + Coins**\
I tinkered with aggregator references and tried creating a fungible asset out of them, but realized the feature wasn’t fully integrated in the version of the Supra framework we were using.
So, for a while, I had only **one** incomplete contract called **`wSup`**. No aggregator or stable bridging in sight, no seamless approach to borrowing—just a partial wrapper. I spent countless late nights reading Move code from random GitHub repos that *never* went to mainnet, hoping to find a snippet or pattern to fix my design.
**Self-admittedly,** I’m not a Move wizard or a dev who can do all by myself. But I kept **listening**, **researching**, and **trial-and-erroring** until I found a structure that was stable enough to be (eventually) audited or extended.
#### **3.2 The Final Three (for Now)**
That’s when it dawned on me: to build a robust lending and borrowing system, I’d need **three** distinct modules—**plus** an oracle. With a bit more referencing, reading, and help, I ended up with:
1. **`price_oracle.move`**
* Responsible for mapping coin types to pair IDs, fetching up-to-date prices from `supra_oracle_storage`, and storing them in an aggregator-friendly format.
2. **`lending_market.move`**
* The heart of the **borrow/lend** logic.
* Contains functions like `deposit`, `borrow`, `repay`, and `withdraw_collateral`.
* Also tracks protocol-level totals in USD, e.g., `total_borrowed_usd` and `total_supplied_usd`.
3. **`obligation.move`**
* Manages user-level collateral and debt obligations.
* Functions like `deposit_collateral`, `withdraw_collateral`, `borrow`, `repay`, and `liquidate` revolve around an **individual** user’s positions.
* Maintains the user’s “health factor” or LTV ratio.
**Why three modules?** Because I needed a separation of concerns:
* **Oracle** data is updated frequently and shouldn’t cross-pollinate heavily with the user’s account data.
* **Lending** in a general sense belongs in its own module—**pool** variables, total interest, etc.
* **Obligations** are personal, user-specific data that must remain decoupled for security. (We can’t have an entire protocol’s state living inside each user’s resource.)
With these three, plus a smaller **`decimal.move`** module for scaling math, I finally felt confident in the architecture. It’s **clean**, **loosely coupled**, and can be **audited** more easily than a single monster contract **(WHICH I WILL DO ONCE I HAVE SUBMITTED THIS AFTER A MONTH OF NON STOP GRINDING FOR THIS)**\
\
I genuinelly do believe in this here and I hope that from my work ethic of working alone that I can hopefully maybe potentially - be in for runner up but alot of the stuff I wanted todo such as a Gas Station Service for Dapps which I was meant to add and alot of other things such as monitoring the pools via an Indexer were all set up within the contracts but on the front end of the website It wasnt done ( I am not a webdesign guy) But the foundational steps are there to create it and that's what I am content with - If I dont do well in this then well there you go I have something I can strive togo on forward with to make better but less of my sob story and more of how to use wSUP!
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://boringity.gitbook.io/wsup-mvp-draft/whatsup.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.