Tangible v2
  • Protocol Overview
    • General
    • Legal
    • Technical
    • Audits & Security
    • RWA (TNGBL) Token
    • Contracts & Addresses
      • Deprecated/Historic Addresses
    • re.al Network Details
    • Protocol Guides and Videos
      • How to Mint and Redeem USTB
    • Archive
      • TNGBL Token
  • Asset Categories
    • Real Estate
      • Sales and Management
      • Marked Rates of Return
      • Decentralized Property Values
        • Roles and Responsibilities
        • Workflow
      • Property Valuation and Underwriting Disclosure
    • Gold
  • Baskets
    • Overview
    • Why Tokenized Real Estate?
    • Design
    • Technical
      • Contracts and Functions
      • Guides
    • FAQs
    • Contracts & Addresses
  • USTB
    • USTB Token
    • USTB Yield
    • Backing Asset: USDM
      • USDM Product Structuring
      • USDM Reserves
      • USDM Reserves: Attestations
      • USDM Reserves: Investment Mandate
      • Risks
      • Security Resources
      • U.S. Restrictions/Terms & Conditions
Powered by GitBook
On this page
  • Basket.sol
  • BasketManager.sol
  • BasketsVrfConsumer.sol
  • Beacon Proxy Pattern
  1. Baskets

Design

PreviousWhy Tokenized Real Estate?NextTechnical

Last updated 1 year ago

Basket.sol

The ERC-20 contract that facilitates the transaction of Basket tokens and TangibleNFTs. These can be created by anyone who holds a TangibleNFT. A new basket can be deployed via the Basket Manager.

BasketManager.sol

This is also known as the “basket factory”. This contract tracks all existing baskets and allows anyone who is holding a TangibleNFT (of a supported tnftType) to deploy a new unique basket via `deployBasket`.

BasketsVrfConsumer.sol

To facilitate the random redeemables in each basket, we’ve decided to build a single BasketsVrfConsumer contract that handles all entropy requests from all baskets. This contract will keep track of all outstanding vrf requests made and route the proper vrf coordinator callback to the designated basket.

Beacon Proxy Pattern

The BeaconProxy contracts would read from the UpgradeableBeacon when performing any executables. The UpgradeableBeacon would hold the implementation address of the only Basket base contract. In the event the Basket logic needs to be updated, all we’d need to do is update the implementation address on the UpgradeableBeacon.

The Basket architecture utilizes the . This allows us to have multiple deployed proxies that all share a single implementation. There only exists 1 Basket.sol on-chain to act as our implementation contract. The BasketManager would deploy a new BeaconProxy contract when a new basket is created.

OZ Beacon Proxy pattern