# Overview
A comprehensive infrastructure for real-world asset (RWA) tokenization to get to market quickly and access global investors at scale
***
## **Project Overview**
Libertum offers a fully comprehensive, scalable, and licensed infrastructure tailored for real-world asset tokenization and access to new financial opportunities.
Libertum offers a versatile tokenisation protocol alongside a licensed marketplace. This platform supports buying, selling, trading, and engaging with DeFi protocols such as farming and borrowing, all centred around RWAs and security tokens.
Our platform, designed for both institutional and retail use, simplifies the issuance, licensing, transfer, and oversight of tradable digital assets and security tokens. These tokens represent various assets such as real estate, precious metals, commodities, local produce, royalties, securities and many more. Our intuitive solutions empower customers to interact securely with blockchain technology, even without technical expertise.
**Links:**
* Website:
* YouTube:
* Telegram:
* Twitter:
* LinkedIn:
* Coin Market Cap:
* Coin Gecko:
Libertum fosters a collaborative approach within the competitive RWA landscape by actively partnering with other companies to drive industry-wide innovation and elevate standards. Libertum aims to contribute to a more robust and transparent ecosystem for Real World Asset investments, benefiting all stakeholders involved.
# Core Services
Below is an overview of the core services offered by Libertum's ecosystem
Ecoystem map of Libertum's core products
Libertum provides a suite of core services that enable users to engage with tokenized assets and DeFi opportunities. These services are built to ensure secure, regulatory compliant, and efficient management of assets and investments on the blockchain.
#### 🔶 **TOKENIZE**
*"TOKENIZE"* is Libertum's tokenization engine, designed to create and manage security tokens using the Ethereum-based ERC1400 standard. It integrates ERC20 functionalities for transactional ease and an ERC721 wrapper for unique visual representation. This service allows for precise control over token partitioning, regulatory compliance through on-chain identity verification, and efficient management of assets on the blockchain, providing a structured approach to asset tokenization.
#### 🔶 **MARKETPLACE**
The Libertum Marketplace facilitates the trading of tokenized real-world assets. It leverages blockchain technology to provide a secure and transparent platform where users can buy, sell, or trade tokenized shares. With features like advanced search tools, automated settlements via smart contracts, and a user-friendly interface, the Marketplace supports efficient transactions and enhances liquidity for tokenized assets.
#### 🔶 **BORROW**
"BORROW" is Libertum's lending market that enables secured loans against tokenized real-world assets. Operating on a decentralized, non-custodial framework, this service allows asset owners to leverage their holdings to obtain liquidity. Smart contracts automate the loan process, from application to repayment, ensuring compliance and transparency. The lending market is designed to offer competitive fixed yield rates while providing a secure environment for both borrowers and lenders.
🔶 **FARM**
The Yield Farming application on Libertum incentivizes users to stake their tokens and earn returns based on the performance of tokenized real-world assets. It offers flexible staking options and dynamic yield rates that adjust according to market conditions and asset performance. By employing smart contracts for automated yield distribution, this service supports efficient reward allocation and enhances the value of holding Libertum tokens.
🔶 **EARN**
"EARN" provides a decentralized staking portal for $LBM tokens, allowing users to allocate their tokens across multiple smart contract pools with varying APY rates and lock-up durations. This service is designed to optimize returns based on users' commitment periods, with staking rewards ranging from 5% to 40% APR. EARN also focuses on transparency and community engagement, providing regular insights and updates for $LBM token holders.
🔶 **GET**
The Libertum "GET" tool allows users to swap their tokens on the Ethereum Layer 2 network, Base, to acquire more $LBM. This service facilitates efficient token management and liquidity within the Libertum ecosystem, offering a straightforward method for users to increase their $LBM holdings.
🔶 **CHOOSE**
Coming soon.
🔶 **STAY**
Coming soon.
### Conclusion
Libertum's core services are developed to provide a comprehensive and compliant framework for engaging with tokenized real-world assets. By integrating advanced blockchain technology and strategic partnerships, Libertum aims to enhance the accessibility, liquidity, and efficiency of RWA investments, supporting both asset owners and investors in a secure and regulated environment.
# The Libertum Team
See the team at https\://www\.libertum.io/team or chat directly with them every Wednesday at 11am UTC via the Discord Channel.
## LEADERSHIP
#### 🔶 Javvad Azam, **Founder and CEO**
Chartered accountant with +20 years of experience in real estate and hospitality investments, with a passion for Web3 technologies. He is deeply committed to leading transformative projects in real-world asset tokenization to leverage blockchain's potential for global impact.
#### 🔶 Alan Gormley, **Founder and CSO**
A highly seasoned, and proven COO with expertise in driving growth through effective strategic business and product development. With expertise in Web3 technologies and real estate, his goal is setting new standards for Web3 engagement and valuing creation while bridging the traditional Web2 world.
#### 🔶 Kevin Upton, CTO
Bio pending
#### 🔶 Xavier Litt, **CMO**
Xavier is an expert in Digital Marketing with over 10 years of experience in Advertising Technologies and Machine Learning applied to digital marketing, as well as a crypto enthusiast. He is also the founder of Ad360, an innovative AI advertising platform. He now serves as the fractional Chief Marketing Officer at Libertum, bringing his expertise to the team.
## TECHNOLOGY
#### 🔶 Mateusz Wuzik, Senior Frotnend and DevOps
Mateusz, as a Software Architect, combines technical expertise with strategic thinking to design advanced software systems. He is responsible for developing high-level architectural concepts that ensure all software components work together in an efficient, scalable, and secure manner. His role involves analyzing business requirements, selecting appropriate technologies and tools, and overseeing the entire software development process, from the conceptual phase to deployment. Mateusz has a deep understanding of various programming languages, design patterns, and databases, with extensive experience working with development teams.
#### 🔶 Chris Tham, Head of Blockchain
Chris is a software engineer living in the Bay Area, California. He has been in the web3 space for 5 years and is committed to the vision of a decentralized and trustless future. He has previously worked on systems and tooling for AI research, and is currently focused on building the suite of smart contracts and blockchain infrastructure that powers Libertum's mission of democratizing real estate.
#### 🔶 Kamil \[Insert last name], Senior Frontend Engineer
Bio pending
#### 🔶 Nicole \[Insert last name], Frontend Developer
Nicole, an Argentine Front End developer, stands out for her specialized focus on UX/UI design. Her passion for creating captivating digital experiences is combined with a collaborative nature that enjoys teamwork. Nicole possesses strong technical skills and a fervent drive for pioneering solutions , particularly in the field of blockchain technology.
#### 🔶 Guillermio \[Insert last name], Full Stack Engineer
Guillermo is a committed Full-Stack Engineer from Argentina with a strong passion for blockchain technology and smart contracts. With experience in both front-end and back-end web development, he is always eager to learn cutting-edge technologies to expand his expertise in these areas.
## **GROWTH**
#### 🔶 Diarmuid Maddock, Head Of Growth
With 4 years of direct experience in tokenization environments, Diarmuid Maddock is a seasoned professional with a strong background in operations and business development within blockchain startups. Throughout his career, he has collaborated with prestigious entities, including Tokeny, Black Manta and Centrifuge, and has previously worked at RWA protocols, Defactor and InvoiceMate. Currently, as Head of Growth, Diarmuid drives the expansion and strategic initiatives at Libertum, focusing on enhancing market presence and business development. His passion lies in security tokens, on-chain trading, DeFi strategies, and tokenomics.
#### 🔶 Rabert, Product Manager and Strategist
Rabert is an economist based in Thailand with deep experience in the Web3 sector. Over the past five years, he has served as a consultant on numerous projects, providing expert guidance on product development, tokenomics, and crafting unique value propositions. His extensive background as an investor further enhances his ability to help projects navigate the complexities of the decentralized economy, bringing valuable insights and strategic direction to each initiative he supports.
#### 🔶 Ephraim Akinolada, **Community Manager**
Ephraim is a seasoned Community Growth Strategist. With over four years of experience, he has developed a deep understanding of DeFi. Ephraim excels at creating impactful communication and marketing strategies that align with specific objectives and uphold the company’s brand values. At Libertum, he is committed to driving global community growth through strategic engagement and innovative campaigns.
#### 🔶 Daniel Akinolada, **Community Associate**
Daniel is a Community Manager with expertise in building and nurturing communities, bringing over three years of experience in managing various communities within the Web3 space. At Libertum, Daniel aims to create a safe, inclusive, and engaging environment where members can freely share their thoughts and ideas. He is committed to upholding the community's values and principles while fostering a positive atmosphere for everyone involved.
# TOKENIZE
TOKENIZE: The Magic Behind Tokenization at Libertum
***
## **Overview**
The Tokenization Engine or "TOKENIZE" utilizes the Ethereum-based ERC1400 standard, designed for the secure and compliant issuance and management of security tokens. This engine integrates ERC20 functionalities for transactional ease and an ERC721 wrapper for unique visual representation, ensuring each token is both functionally robust and engaging for users.
### Functional Description
🔸 *Security Token Creation:* Utilizes ERC1400 for the creation of highly customizable security tokens.
🔸 *Partitioning and Granularity:* Allows for precise control over token division and transactional granularity, enhancing flexibility in token management.
🔸 *Transfer Restrictions:* Implements comprehensive controls over token transfers, ensuring compliance with regulatory requirements through on-chain identity verification.
### **Key Features**
🔸 *ERC1400 Standard:* Supports advanced security token functionalities such as document management and controlled token operations.
🔸 *ERC721 Wrapper:* Provides a non-fungible visual representation of security tokens, enhancing user interaction and engagement.
🔸 *ERC20 Compatibility:* Ensures the tokens can interact seamlessly with standard cryptocurrency tools and exchanges.
### Technical Specifications
🔸 *Token Management:* Manages tokens through roles like controllers and operators who can issue, redeem, or transfer tokens based on defined permissions.
🔸 *Document Attachment:* Facilitates attachment of documents to tokens, increasing transparency and regulatory compliance.
🔸 *Visual Representation:* Each token features a corresponding ERC721 token that visually represents ownership or specific attributes associated with the security.
### Process Flow
1️⃣ *Legal Compliance and Documentation:* Preparation and review of all necessary legal documents associated with the asset.
2️⃣ *Asset Registration:* Input of detailed asset information into Libertum’s platform, ensuring comprehensive documentation and verification.
3️⃣ *Token Configuration:* Definition of token properties such as name, symbol, granularity, and partition rules in alignment with ERC1400 standards.
4️⃣ *Visual Design and Implementation:* Design and selection of the visual representation for the ERC721 wrapper, tailored to represent unique asset features.
5️⃣ *Deployment and Trading:* Deployment of the tokenized asset on the blockchain, making it ready for trading and investment on the Libertum platform.
### **Conclusion**
The Tokenization Engine or "TOKENIZE" stands as a cornerstone of the Libertum platform, offering a detailed and methodical approach to asset tokenization. It ensures that each security token not only meets the highest standards of regulatory compliance but also offers a rich, engaging user experience through its visual representation and interaction capabilities.
***
# MARKETPLACE
MARKETPLACE: Trading of Tokenized Assets
***
### Overview
The Libertum Marketplace is an integral component of the platform, designed to facilitate the trading of tokenized real-world assets (RWA). This digital marketplace leverages blockchain technology to ensure secure, transparent, and efficient transactions, enabling users to buy, sell, or trade shares of tokenized assets with ease.
#### Functional Description
🔸 *Trading Platform:* Provides a robust environment for the buying, selling, and exchanging of tokenized shares.
🔸 *Liquidity Enhancement:* Promotes a liquid market for tokenized assets, allowing for quick and efficient asset trades.
🔸 *User Interaction:* Features an intuitive user interface that simplifies navigation and transaction processes for all user levels.
#### Key Features
🔸 *Real-Time Trading:* Supports immediate transaction execution on the blockchain, ensuring that all trades are timely and reflect current market conditions.
🔸 *Advanced Search and Filter Tools:* Enables users to efficiently find specific assets based on various criteria such as asset type, value, and expected returns.
🔸 *Automated Settlements:* Utilizes smart contracts for the automated settlement of trades, reducing the need for manual intervention and enhancing transaction security.
#### Technical Specifications
🔸 *Blockchain Integration:* Utilizes Ethereum blockchain technology to record all transactions securely and immutably.
🔸 *Smart Contract Functionality:* Employs smart contracts to manage the lifecycle of each trade, from initiation to completion, ensuring compliance and enforcement of agreed terms.
🔸 *Security Protocols:* Implements rigorous security measures to protect user data and transaction integrity.
#### Process Flow
1️⃣ *Asset Listing:* Owners list their tokenized assets on the marketplace, including detailed descriptions and terms of sale.
2️⃣ *Buyer Discovery:* Potential buyers use the platform’s search and filter tools to find assets that match their investment criteria.
3️⃣ *Transaction Execution:* Buyers place orders, which are matched with available listings. Smart contracts facilitate the secure exchange of assets and funds.
4️⃣ *Post-Trade Processing:* The platform handles all aspects of trade settlement, updating asset ownership records on the blockchain and ensuring that funds are correctly transferred to the seller.
5️⃣ *Ongoing Trading Support:* The marketplace provides continuous support for repeat transactions, offering tools for performance tracking and portfolio management.
#### Conclusion
The Libertum Marketplace is designed to be a dynamic and user-friendly platform that not only supports the efficient trading of tokenized assets but also enhances the overall liquidity of the investment landscape. By integrating advanced blockchain solutions and smart contract technology, the marketplace ensures that all transactions are conducted securely, transparently, and in compliance with regulatory standards.
***
# BORROW
BORROW: Lending & Borrowing
***
#### Overview
The lending market is a B2B protocol that connects centralised banks, lenders, and DeFi protocols, creating an engaging ecosystem for financial innovation to tokenised asset owners.
Lending markets enable asset owners to leverage tokenised real-world assets, establishing interest rates, transaction amounts, repayment terms, and loan expiration dates. A successful lending and borrowing market hinges on the participation of both lenders and borrowers.
The lending market offers users the ability to swiftly and effortlessly borrow against their collateralised real-world assets.
Asset owners initiate borrowing requests by submitting their asset contracts and funding requirements. A panel of liquidity providers evaluates this information. Upon passing the eligibility test, asset owners receive notifications detailing available offers and terms for borrowing against their collateralised assets. They can then review and select the proposal that best meets their needs.
#### Functional Description
🔸 *Secured Loan Provisioning:* Offers a platform for users to obtain loans by collateralizing their tokenized assets.
🔸 *Fixed Yield Rates:* Delivers competitive fixed yield rates by interfacing with various yield protocols to optimize returns for lenders.
🔸 *Streamlined Loan Processing:* Simplifies the loan application and disbursement process, enhancing user experience and access to funds.
#### Key Features
🔸 *Automated Loan Management:* Uses smart contracts to manage the entire loan process from application to repayment, ensuring efficiency and reducing the potential for errors.
🔸 *Dynamic Interest Rate Adjustment:* Integrates with external DeFi protocols to continually adjust offered rates based on prevailing market conditions.
🔸 *Enhanced Liquidity:* Provides liquidity to asset owners quickly by ensuring that loan agreements are executed promptly and funds are disbursed without unnecessary delays.
#### Technical Specifications
🔸 Smart Contract Architecture: Utilizes Ethereum smart contracts to enforce loan terms, manage collateral, and handle repayments.
🔸 Collateral Management: Implements robust mechanisms to evaluate, lock, and manage collateral throughout the loan lifecycle.
🔸 Regulatory Compliance: Ensures all lending activities adhere to applicable financial regulations, safeguarding both borrowers and lenders.
#### Process Flow
1️⃣ *Collateral Tokenization:* Asset owners tokenize their properties or other assets, which are assessed and approved for collateralization.
2️⃣ *Loan Application:* Borrowers apply for loans by specifying the amount needed and terms, and collateralizing their tokenized assets.
3️⃣ *Rate Optimization:* The platform automatically sources and recommends the best available lending rates by analyzing various DeFi protocols.
4️⃣ *Loan Approval and Disbursement:* Once approved, loans are disbursed directly to the borrower’s wallet, with all terms enforced via smart contracts.
5️⃣ *Repayment and Collateral Release:* Borrowers fulfill their repayment obligations as per the agreed schedule. Upon complete repayment, collateral is released back to the borrower’s control.
#### Conclusion
The Libertum Lending Market is a pivotal component that enhances the utility of tokenized assets by providing a secure and efficient mechanism for asset-backed lending. By leveraging blockchain technology and smart contracts, the platform ensures that all lending activities are transparent, compliant, and aligned with the users' financial needs. This approach not only fosters trust and participation in the Libertum ecosystem but also contributes to the broader financial empowerment of asset owners.
***
# FARM
TRADE: RWA Yield Farming
***
## Overview
Libertum's Yield Farming application is a core component designed to incentivize and reward investors for staking their tokens. This platform feature allows users to earn returns from their investments in tokenized real-world assets (RWAs), enhancing the value proposition of holding and investing in tokenized assets.
Libertum's yield farming presents a unique opportunity for users to stake stable tokens, unlocking high yields from income-generating assets linked to real-world physical assets. Real-world assets yield farming allows users to lock stable tokens, much like Aerodrome. The dashboard should feature a variable annual percentage rate (vAPR), which begins high and gradually decreases as more participants engage in the farming process for the same yield.
### Functional Description
🔸 Stake and Earn: Users can stake their Libertum tokens to earn yields based on the performance and revenue generated from the underlying real-world assets.
🔸 Flexible Staking Options: Offers various staking options with different terms and reward structures to accommodate diverse investor preferences and risk appetites.
🔸 Automated Yield Distribution: Utilizes smart contracts to calculate and distribute yields automatically, ensuring transparency and fairness in reward allocation.
### Key Features
🔸 **Access to Yield Farming Pool:** Users should be able to navigate to the "Yield Farming" section within the platform, which provides an overview of various pools available for staking stable tokens.
🔸 **Overview of vAPR and Staking Information:**
* Display the current vAPR of the pool and how it changes based on the number of staked tokens.
* Indicate pool saturation thresholds at which vAPR gradually decreases to incentivize early adoption.
🔸 **Locking & Unstaking Mechanism:**
* Allow users to lock their stable tokens into the farming pool for a specified duration.
* Show rewards calculated in real-time based on current vAPR, user’s staked amount, and total amount staked.
🔸 **Reward Calculation & Distribution:**
* Reward users proportionally based on the locked amount and time period of staking.
* Distribute rewards in stable tokens or native platform tokens, which can also be staked for compound rewards.
🔸 **Yield Curve Visualization:**
* Display a yield curve indicating the trend of vAPR as more users join the pool. This helps users understand how their potential earnings might change with pool saturation.
🔸 **Automated vAPR Adjustment:**
* The platform should have a smart contract that automatically adjusts the vAPR based on the number of tokens locked by all users.
### Technical Specifications
🔸 Smart Contract Implementation: Deployed on the Ethereum blockchain, utilizing smart contracts to manage all aspects of yield farming, from staking to yield calculation and distribution.
🔸 Security Protocols: Implements rigorous security measures to protect the integrity of staked assets and distributed yields.
🔸 Integration with DeFi Protocols: Interfaces with various decentralized finance protocols to ensure optimal yield generation and asset liquidity.v
### Process Flow
1️⃣ *Token Staking:* Investors stake their Libertum tokens through a user-friendly interface on the Libertum dashboard.
2️⃣ *Yield Calculation:* The platform calculates yields based on pre-determined formulas that consider the asset's performance, market conditions, and the amount of tokens staked.
3️⃣ Y*ield Distribution:* Yields are distributed to stakers at regular intervals, directly to their wallets, in a transparent and automated manner.
4️⃣ Unstaking and Liquidity: Provides options for unstaking tokens, allowing investors to reclaim their tokens along with the accrued yields after the staking period ends, maintaining liquidity and flexibility.
### Conclusion
The Yield Farming application is an essential mechanism within the Libertum ecosystem, designed to foster a robust investment environment by rewarding long-term token holders. It not only drives platform engagement and token utility but also aligns the interests of the investors with the performance of the underlying assets, creating a community-driven investment model that is sustainable and profitable.
# CHOOSE
CHOOSE: Libertum's Governance Protocol
***
# EARN
Our Staking Solution
***
## Overview
EARN offers a decentralized portal for directly staking $LBM tokens across five distinct smart contract pools, each featuring unique annual percentage yield (APY) rates and varying lock-up durations. This staking mechanism allows users to allocate their $LBM tokens in different liquidity pools, optimizing their returns based on preferred commitment periods.
Stake your LBM now at: earn.libertum.io
### **Staking Rewards**
The rewards for staking are quite lucrative, with annual percentage rates (APRs) ranging from 5% to a staggering 40% depending on the pool the tokens have been staked.
### Community
EARN is designed to enhance community engagement and provide valuable insights for $LBM token holders. By prioritising transparency and striving to provide users and partners with reliable, up-to-date information, EARN fosters an environment of active involvement for the $LBM community. \
\
A governance vote is planned to be implemented by Q4 2024, subject to the necessary approvals and conditions.
### **Defactor & Libertum**
Libertum has partnered with RWA leader Defactor to leverage their technology for introducing $LBM staking and governance to token holders. This collaboration aims to expand the utility and market reach of both projects, with ongoing efforts to explore further synergies and opportunities.
# GET
Easily obtain LBM tokens with just a few clicks.
***
The Libertum GET tool allows users to swap their tokens on the Ethereum Layer 2 network, Base, to "GET" more $LBM.
1️⃣ Connect your wallet.
2️⃣ Select the token you wish to exchange for $LBM.
3️⃣ Approve the selected token for the transaction.
4️⃣ SWAP the token to receive $LBM.
#### [Audit](https://github.com/solidproof/projects/tree/main/2024/Libertum) and [KYC](https://github.com/solidproof/projects/tree/main/2023/Libertum) powered by [SolidProof](https://solidproof.io/)
# Technical Overview
## 1. Introduction
Libertum.io is a real-world asset (RWA) tokenization platform, designed to enable the seamless integration of physical and financial assets into the blockchain ecosystem. By tokenizing these assets, Libertum.io bridges traditional finance and blockchain technology, making it easier for users to create, manage, and transfer tokenized assets across decentralised and centralised finance platforms. The platform offers a secure and efficient way to fractionalize ownership of assets, providing liquidity and opening new avenues for financial participation.
***
### 2. Core Functionality
#### **Asset Tokenization**
At the core of Libertum.io, asset tokenization converts real-world assets such as real estate, commodities, and financial instruments into digital tokens that exist on the blockchain. Each asset is represented as a security token, compliant with the ERC-1400 standard (see blockchain integration), enabling:
* Fractional Ownership: Physical assets can be divided into smaller, tradable units, allowing users to own a fraction of high-value assets like real estate or fine art.
* Increased Liquidity: Tokenized assets can be traded on digital marketplaces, offering greater liquidity for traditionally illiquid assets.
* Transparency: Every transaction is recorded on the blockchain, providing full transparency and immutability.
#### **Ownership Representation**
Libertum.io enables ownership of tokenized assets through blockchain-based security tokens. These tokens:
* Represent legal ownership or entitlement to a share of the underlying real-world asset.
* Are fully transferable between users on the platform or across blockchain ecosystems, allowing for seamless ownership exchange.
* Allow for easy, verifiable proof of ownership through a blockchain explorer, creating a trustless environment for asset exchange.
#### **Asset Management**
To facilitate seamless interaction with tokenized assets, Libertum.io provides comprehensive asset management tools:
* Tracking: Users can monitor their asset portfolios in real-time, including value fluctuations, ownership changes, and more.
* Management: Secure tools for transferring and managing their tokens between wallets or platforms.
* Automated Updates: Any changes in the underlying asset, such as price appreciation or depreciation, are reflected in the user’s tokenized holdings on the blockchain.
#### **Marketplace Integration**
The platform includes an integrated marketplace where users can:
* Buy, Sell, or Trade tokenized assets with other users in a transparent and secure environment.
* Discover New Assets: Access a wide range of tokenized assets, from real estate and financial instruments to digital assets, with the potential for global liquidity.
* Set Bids and Offers: Implement traditional trading strategies such as setting buy/sell orders and participating in auctions for tokenized assets.
#### **Farming Integration**
Libertum.io includes yield farming capabilities, where users can:
* Farm Yield: Tokenized assets that generate a yield (such as rental income from real estate or dividends from stocks) can be staked in farming pools.
* Earn Rewards: Users earn rewards based on the yield produced by the underlying asset, allowing for passive income generation from tokenized assets.
* Flexible Farming Options: The platform provides different farming pools based on asset types, risk profiles, and reward rates.
#### **Lending**
Libertum.io supports both centralised and decentralised lending options, enabling users to leverage their tokenized assets for loans:
* Off-Chain Lending: Users can take their tokenized assets to centralised lending platforms, using them as collateral for fiat loans, enabling liquidity without selling the asset.
* On-Chain Lending: Alternatively, users can access decentralised finance (DeFi) lending platforms, offering their tokenized assets as collateral for crypto loans, benefiting from a decentralised lending ecosystem.
* Dual Lending Options: By offering both options, Libertum.io gives users flexibility based on their risk tolerance and financial goals.
***
### 3. Blockchain Integration
#### **ERC-1400 Security Token**
Libertum.io adheres to the ERC-1400 standard, a blockchain standard designed for the tokenization of securities. ERC-1400 offers advanced features tailored for security tokens:
* Investor Management: Allows for restrictions on who can hold and transfer tokens, making the platform compliant with financial regulations (e.g., KYC/AML).
* Transparency: Provides detailed information on ownership, allowing both token holders and issuers to track who owns which portion of the asset at any given time.
* Security and Compliance: Incorporates mechanisms for enforcing compliance rules at the token level, including the ability to freeze or revoke tokens if necessary.
#### **ERC-721 Security Position**
In addition to fungible tokens, Libertum.io also offers ERC-721 NFTs to represent users' security positions in a more visual and detailed manner:
* Visual Representation: Each token holder’s security position is represented as an NFT, which serves as a wrapper for the underlying ERC-1400 token.
* Unique Metadata: The NFTs include detailed metadata about the holder’s assets, ownership, and performance, providing an intuitive and accessible way to manage tokenized securities.
* Enhanced User Experience: This visual representation allows users to quickly understand their asset holdings and performance, enhancing the overall asset management experience.
#### **Cross-Chain Communication**
Libertum.io leverages cross-chain communication protocols, enabling:
* Seamless Asset Transfer: Tokenized assets can be moved across different blockchain ecosystems effortlessly, ensuring compatibility with multiple DeFi and CeFi platforms.
* Multi-Chain Integration: Allows users to utilise their security tokens on various platforms, benefiting from DeFi applications such as liquidity pools, yield farming, and staking on chains like Ethereum, Binance Smart Chain, or Polygon.
* Interoperability: Cross-chain functionality ensures that tokenized assets are not confined to a single blockchain, increasing liquidity and user choice across multiple financial ecosystems.
***
### 4. Blockchain Security and Compliance
#### **Smart Contract Audits**
Security is paramount for tokenized assets, and Libertum.io ensures the integrity of the platform by conducting comprehensive smart contract audits:
* Third-Party Audits: All smart contracts are rigorously tested and audited by reputable third-party firms to detect and mitigate vulnerabilities.
* Ongoing Security Testing: Regular security reviews are performed, ensuring that smart contracts remain secure as the platform evolves.
#### **Compliance with Regulations**
As a platform tokenizing real-world assets, Libertum.io strictly adheres to regulatory frameworks such as:
* KYC/AML Compliance: All users must undergo Know Your Customer (KYC) and Anti-Money Laundering (AML) procedures to ensure compliance with global financial regulations.
* Securities Regulations: The platform is designed to comply with securities regulations in different jurisdictions, ensuring that asset tokenization remains legally compliant.
* Investor Protections: Built-in features within the ERC-1400 standard ensure that token issuers can enforce regulatory compliance directly through smart contracts, protecting both issuers and investors.
#### **Data Encryption**
To maintain user privacy and data integrity, Libertum.io employs industry-standard data encryption practices:
* In Transit: All data transmitted between users, the platform, and external systems is encrypted using TLS to prevent interception or tampering.
* At Rest: Sensitive information, including personal user data and financial information, is stored in encrypted databases, ensuring that even in the event of a data breach, the data remains protected.
***
# TOKENOMICS
LBM is the governance and utility token of the Libertum Ecosystem. It enables holders to participate in staking, governance and benefit from Libertum's upward trajectory.
LBM inherits the ERC-20 token standard for standard token behaviour.
## Allocations & Vestings
| Allocation | # of Tokens | Vesting |
| -------------------- | ----------- | ----------------------------------------------------- |
| Treasury | 50,000,000 | 0% TGE, use subject to governance vote |
| Team Token | 50,000,000 | 0% TGE, 12 month cliff, linear release over 48 months |
| Staking Rewards | 8,000,000 | 0% at TGE |
| Marketing & Airdrop | 6,000,000 | 0% at TGE |
| Ecosystem & Partners | 28,000,000 | 0% at TGE |
| Exchange & Liquidity | 58,000,000 | 0% at TGE |
# UTILITY
This page describes the different use-cases for the $LBM token, and the potential benefits to arise from them.
### 🔶 Buyback and Burn Mechanism
To support the value of $LBM tokens, a portion of the company's profits will be allocated to a Buyback and Burn mechanism. This strategy involves purchasing $LBM tokens from the market and subsequently burning them, effectively reducing the circulating supply. As the supply decreases, the value of $LBM tokens could potentially increase, providing significant benefits to stakeholders.
#### Key Benefits:
* **Reduction in circulating supply:** By consistently burning tokens, the total supply of $LBM decreases over time, potentially driving up the token's value.
* **Increased value for stakerholders:** As the value of $LBM rises, stakers are likely to see a significant boost in the worth of their holdings.
### 🔶 Governance Rights
The $LBM governance protocol, "CHOOSE" is scheduled for release by Q4 2024. This will empower token holders with the ability to participate in decision-making processes related to the ecosystem.
#### Key Details:
* **Governance Protocol Release:** Expected by Q4 2024.
* **Staking requirement:** Asset tokenizers will be required to purchase and stake $LBM tokens for a minimum of 12 months in order to have their assets tokenized within the @libertum\_token infrastructure. This requirement ensures long-term commitment and alignment with the ecosystem’s goals.
### 🔶 Asset Tokenizers
Asset tokenizers who wish to tokenize their assets within the Libertum infrastructure will be required to demonstrate a long-term commitment to the ecosystem.
#### Key Requirements:
* **Mandatory staking:** Asset tokenizers must buy and stake $LBM tokens for a minimum of 12 months to have their assets tokenized. This staking requirement ensures alignment with the ecosystem’s goals and contributes to the stability and growth of the $LBM token economy.
### 🔶 Lending Protocol
The lending protocol offers attractive incentives for those who buy and stake $LBM tokens.
#### Key Benefits:
* **Interest rate boost:** By staking a minimum of 10,000 $LBM, lenders receive a boost in their interest rate.
* **Example:** If the base rate offered by a liquidity provider is 7.5%, borrowers can receive a 0.1% discount, reducing their borrowing rate to 7.4%, provided they have staked $LBM for at least 12 months.
### 🔶 Farming Market
Yield farmers can significantly enhance their returns by staking $LBM tokens.
#### Key Benefits:
* **Yield boost:** Staking a minimum of 10,000 $LBM provides a 2.5% boost to yield payments.
* **Example:** If a yield farmer invests in an asset offering a 10% annual yield, staking 10,000 $LBM for the full term will increase their total return to 10.25% per year.
This approach benefits both yield farmers and $LBM token holders by increasing demand for $LBM, thereby potentially driving up its value.
### Conclusion
The $LBM token is integral to the Libertum ecosystem, offering multiple avenues for value creation, from governance participation to financial incentives through buyback and burn mechanisms, lending protocols, and yield farming enhancements. Holding and staking $LBM not only supports the ecosystem but also provides tangible benefits to its holders.
# WHERE TO FIND LBM?
Description of token locality:
### Token details:
LBM contract address: **0x56a38e7216304108e841579041249feb236c887b**\
Network: Base (Ethereum L2)\
Etherscan:
### To add Base as a custom network to MetaMask:
1. Open the MetaMask browser extension.
2. Open the network selection dropdown menu by clicking the dropdown button at the top of the extension.
3. Click the **Add network** button.
4. Click **Add a network manually**.
5. In the **Add a network manually** dialog that appears, enter the following information for Base mainnet:
| Name | Value |
| --------------- | ----------------------------------------------------- |
| Network Name | Base Mainnet |
| Description | The public mainnet for Base. |
| RPC Endpoint | [https://mainnet.base.org](https://mainnet.base.org/) |
| Chain ID | 8453 |
| Currency Symbol | LBM |
| Block Explorer | |
6. Tap the Save button to save Base as a network.
You are now ready to swap tokens on the Base network.
# LBM on Centralised Exchanges
# Page 1
# CONTRACTS
# Security Token
## Security Token Documentation
### Introduction
The Security Token system is designed to create and manage tokenized securities on the blockchain. It implements the ERC1400 standard, which extends ERC20 functionality with features specific to security tokens, such as transfer restrictions and partitioned balances. This system provides a flexible and compliant framework for issuing and managing security tokens.
### Key Components
#### SecurityToken
The main contract that represents a security token. It implements the ERC1400 standard and includes additional features for issuance, redemption, and transfer control.
#### SecurityTokenFactory
A factory contract that deploys new instances of the SecurityToken. It uses the upgradeable beacon pattern for easy upgrades of all deployed instances.
#### ISecurityToken
The interface defining the core functionality of the Security Token system, including initialization parameters and key functions.
### Functionality
#### Token Issuance
Authorized addresses can issue new tokens to specified recipients. This process involves:
1. Calling the `issue` function, specifying the recipient and amount.
2. Optionally providing additional data for the issuance.
#### Token Redemption
Token holders can redeem their tokens, effectively destroying them and potentially receiving underlying assets in return.
#### Transfer Restrictions
The Security Token implements transfer restrictions as per the ERC1400 standard. Transfers can be restricted based on various criteria, including regulatory requirements.
#### Partitioned Balances
Tokens can be divided into different partitions, allowing for more granular control over token ownership and transfers.
#### Controller Operations
Authorized controllers can force transfers between addresses, providing a mechanism for regulatory compliance or legal actions.
### Usage Guide
#### Deploying a Security Token
1. Deploy the SecurityTokenFactory.
2. Call the `deploy` function on the factory, providing initialization parameters:
```solidity
bytes32 stId = keccak256("mySecurityToken");
ISecurityToken.InitializeParams memory params = ISecurityToken.InitializeParams({
name: "My Security Token",
symbol: "MST",
granularity: 1,
controllers: controllers,
defaultPartitions: defaultPartitions,
extension: extensionAddress,
owner: ownerAddress,
minter: minterAddress
});
bytes memory stInitData = abi.encodeWithSelector(SecurityToken.initialize.selector, params);
address deployedSecurityToken = stFactory.deploy(stId, stInitData);
```
#### Issuing Tokens
As an authorized minter:
```solidity
securityToken.issue(recipientAddress, amount, "");
```
#### Redeeming Tokens
As a token holder:
```solidity
securityToken.redeem(amount, "");
```
#### Transferring Tokens
Standard ERC20 transfer:
```solidity
securityToken.transfer(recipientAddress, amount);
```
Transfer with partition:
```solidity
securityToken.transferByPartition(partitionBytes32, recipientAddress, amount, "");
```
#### Checking Transfer Validity
Before attempting a transfer:
```solidity
bytes memory reason = securityToken.canTransfer(recipientAddress, amount, "");
require(reason.length == 0, "Transfer not allowed");
```
#### Managing Controllers
As the token owner:
```solidity
securityToken.addController(controllerAddress);
securityToken.removeController(controllerAddress);
```
### Security Considerations
1. **Access Control**: Ensure that only authorized addresses can call sensitive functions like `issue`, `redeem`, and controller operations.
2. **Transfer Restrictions**: Implement and thoroughly test transfer restriction logic to comply with regulatory requirements.
3. **Upgrades**: The upgradeable beacon pattern allows for upgrades. Ensure that upgrade processes are secure and well-tested.
4. **Partitions**: Be cautious when working with partitioned balances to avoid accounting errors.
5. **Extension Contracts**: If using extension contracts (e.g., for transfer validation), ensure they are secure and properly integrated.
# ERC1400
## ERC1400Upgradeable
[Git Source](https://github.com/Libertum-Project/security-token-contracts/blob/3464d5ab8850f3f8fc835299f95703c8793378ae/src\ERC1400Upgradeable.sol)
**Inherits:** IERC20, IERC1400, ERC1400Storage, OwnableUpgradeable, ERC1820Client, ERC1820Implementer, MinterRoleUpgradeable, DomainAwareUpgradeable
*ERC1400 logic*
### State Variables
#### ERC1400\_INTERFACE\_NAME
```solidity
string internal constant ERC1400_INTERFACE_NAME = "ERC1400Token";
```
#### ERC20\_INTERFACE\_NAME
```solidity
string internal constant ERC20_INTERFACE_NAME = "ERC20Token";
```
#### ERC1400\_TOKENS\_CHECKER
```solidity
string internal constant ERC1400_TOKENS_CHECKER = "ERC1400TokensChecker";
```
#### ERC1400\_TOKENS\_VALIDATOR
```solidity
string internal constant ERC1400_TOKENS_VALIDATOR = "ERC1400TokensValidator";
```
#### ERC1400\_TOKENS\_SENDER
```solidity
string internal constant ERC1400_TOKENS_SENDER = "ERC1400TokensSender";
```
#### ERC1400\_TOKENS\_RECIPIENT
```solidity
string internal constant ERC1400_TOKENS_RECIPIENT = "ERC1400TokensRecipient";
```
### Functions
#### \_\_ERC1400\_init
*Initialize ERC1400 + register the contract implementation in ERC1820Registry.*
```solidity
function __ERC1400_init(
string memory tokenName,
string memory tokenSymbol,
uint256 tokenGranularity,
address[] memory initialControllers,
bytes32[] memory defaultPartitions,
address owner,
address minter
) internal onlyInitializing;
```
**Parameters**
| Name | Type | Description |
| -------------------- | ----------- | -------------------------------------------------------------------------------------------- |
| `tokenName` | `string` | Name of the token. |
| `tokenSymbol` | `string` | Symbol of the token. |
| `tokenGranularity` | `uint256` | Granularity of the token. |
| `initialControllers` | `address[]` | Array of initial controllers. |
| `defaultPartitions` | `bytes32[]` | Partitions chosen by default, when partition is not specified, like the case ERC20 tranfers. |
| `owner` | `address` | |
| `minter` | `address` | |
#### isIssuableToken
Modifiers \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
*Modifier to verify if token is issuable.*
```solidity
modifier isIssuableToken();
```
#### isNotMigratedToken
*Modifier to make a function callable only when the contract is not migrated.*
```solidity
modifier isNotMigratedToken();
```
#### onlyMinter
*Modifier to verifiy if sender is a minter.*
```solidity
modifier onlyMinter() override;
```
#### totalSupply
*Get the total number of issued tokens.*
```solidity
function totalSupply() external view override returns (uint256);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------ |
| `` | `uint256` | Total supply of tokens currently in circulation. |
#### balanceOf
*Get the balance of the account with address 'tokenHolder'.*
```solidity
function balanceOf(address tokenHolder) external view override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | ------------------------------------------ |
| `tokenHolder` | `address` | Address for which the balance is returned. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------------ |
| `` | `uint256` | Amount of token held by 'tokenHolder' in the token contract. |
#### transfer
*Transfer token for a specified address.*
```solidity
function transfer(address to, uint256 value) external override returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------- | --------- | ---------------------------- |
| `to` | `address` | The address to transfer to. |
| `value` | `uint256` | The value to be transferred. |
**Returns**
| Name | Type | Description |
| -------- | ------ | --------------------------------------------------------- |
| `` | `bool` | A boolean that indicates if the operation was successful. |
#### allowance
*Check the value of tokens that an owner allowed to a spender.*
```solidity
function allowance(address owner, address spender) external view override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ----------------------------------------------- |
| `owner` | `address` | address The address which owns the funds. |
| `spender` | `address` | address The address which will spend the funds. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------------------------- |
| `` | `uint256` | A uint256 specifying the value of tokens still available for the spender. |
#### approve
*Approve the passed address to spend the specified amount of tokens on behalf of 'msg.sender'.*
```solidity
function approve(address spender, uint256 value) external override returns (bool);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | --------------------------------------- |
| `spender` | `address` | The address which will spend the funds. |
| `value` | `uint256` | The amount of tokens to be spent. |
**Returns**
| Name | Type | Description |
| -------- | ------ | --------------------------------------------------------- |
| `` | `bool` | A boolean that indicates if the operation was successful. |
#### transferFrom
*Transfer tokens from one address to another.*
```solidity
function transferFrom(address from, address to, uint256 value) external override returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------- | --------- | --------------------------------------------------- |
| `from` | `address` | The address which you want to transfer tokens from. |
| `to` | `address` | The address which you want to transfer to. |
| `value` | `uint256` | The amount of tokens to be transferred. |
**Returns**
| Name | Type | Description |
| -------- | ------ | --------------------------------------------------------- |
| `` | `bool` | A boolean that indicates if the operation was successful. |
#### getDocument
*Access a document associated with the token.*
```solidity
function getDocument(bytes32 documentName) external view override returns (string memory, bytes32, uint256);
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ----------------------------------------------------------------- |
| `documentName` | `bytes32` | Short name (represented as a bytes32) associated to the document. |
**Returns**
| Name | Type | Description |
| -------- | --------- | -------------------------------------------------------- |
| `` | `string` | Requested document + document hash + document timestamp. |
| `` | `bytes32` | |
| `` | `uint256` | |
#### setDocument
*Associate a document with the token.*
```solidity
function setDocument(bytes32 documentName, string calldata uri, bytes32 documentHash) external override;
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ----------------------------------------------------------------- |
| `documentName` | `bytes32` | Short name (represented as a bytes32) associated to the document. |
| `uri` | `string` | Document content. |
| `documentHash` | `bytes32` | Hash of the document \[optional parameter]. |
#### removeDocument
```solidity
function removeDocument(bytes32 documentName) external override;
```
#### getAllDocuments
```solidity
function getAllDocuments() external view override returns (bytes32[] memory);
```
#### balanceOfByPartition
*Get balance of a tokenholder for a specific partition.*
```solidity
function balanceOfByPartition(bytes32 partition, address tokenHolder) external view override returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | ------------------------------------------ |
| `partition` | `bytes32` | Name of the partition. |
| `tokenHolder` | `address` | Address for which the balance is returned. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------------------------------------- |
| `` | `uint256` | Amount of token of partition 'partition' held by 'tokenHolder' in the token contract. |
#### partitionsOf
*Get partitions index of a tokenholder.*
```solidity
function partitionsOf(address tokenHolder) external view override returns (bytes32[] memory);
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | ---------------------------------------------------- |
| `tokenHolder` | `address` | Address for which the partitions index are returned. |
**Returns**
| Name | Type | Description |
| -------- | ----------- | ------------------------------------------- |
| `` | `bytes32[]` | Array of partitions index of 'tokenHolder'. |
#### transferWithData
*Transfer the amount of tokens from the address 'msg.sender' to the address 'to'.*
```solidity
function transferWithData(address to, uint256 value, bytes calldata data) external override;
```
**Parameters**
| Name | Type | Description |
| ------- | --------- | ---------------------------------------------------------- |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens to transfer. |
| `data` | `bytes` | Information attached to the transfer, by the token holder. |
#### transferFromWithData
*Transfer the amount of tokens on behalf of the address 'from' to the address 'to'.*
```solidity
function transferFromWithData(address from, address to, uint256 value, bytes calldata data) external virtual override;
```
**Parameters**
| Name | Type | Description |
| ------- | --------- | --------------------------------------------------------------------------------- |
| `from` | `address` | Token holder (or 'address(0)' to set from to 'msg.sender'). |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens to transfer. |
| `data` | `bytes` | Information attached to the transfer, and intended for the token holder ('from'). |
#### transferByPartition
*Transfer tokens from a specific partition.*
```solidity
function transferByPartition(bytes32 partition, address to, uint256 value, bytes calldata data)
external
override
returns (bytes32);
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ---------------------------------------------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens to transfer. |
| `data` | `bytes` | Information attached to the transfer, by the token holder. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ---------------------- |
| `` | `bytes32` | Destination partition. |
#### operatorTransferByPartition
*Transfer tokens from a specific partition through an operator.*
```solidity
function operatorTransferByPartition(
bytes32 partition,
address from,
address to,
uint256 value,
bytes calldata data,
bytes calldata operatorData
) external override returns (bytes32);
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ------------------------------------------------------------------------------ |
| `partition` | `bytes32` | Name of the partition. |
| `from` | `address` | Token holder. |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens to transfer. |
| `data` | `bytes` | Information attached to the transfer. \[CAN CONTAIN THE DESTINATION PARTITION] |
| `operatorData` | `bytes` | Information attached to the transfer, by the operator. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ---------------------- |
| `` | `bytes32` | Destination partition. |
#### isControllable
*Know if the token can be controlled by operators. If a token returns 'false' for 'isControllable()'' then it MUST always return 'false' in the future.*
```solidity
function isControllable() external view override returns (bool);
```
**Returns**
| Name | Type | Description |
| -------- | ------ | ------------------------------------------------------------------------------------------- |
| `` | `bool` | bool 'true' if the token can still be controlled by operators, 'false' if it can't anymore. |
#### authorizeOperator
*Set a third party operator address as an operator of 'msg.sender' to transfer and redeem tokens on its behalf.*
```solidity
function authorizeOperator(address operator) external override;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ----------------------------------------------- |
| `operator` | `address` | Address to set as an operator for 'msg.sender'. |
#### revokeOperator
*Remove the right of the operator address to be an operator for 'msg.sender' and to transfer and redeem tokens on its behalf.*
```solidity
function revokeOperator(address operator) external override;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | --------------------------------------------------- |
| `operator` | `address` | Address to rescind as an operator for 'msg.sender'. |
#### authorizeOperatorByPartition
*Set 'operator' as an operator for 'msg.sender' for a given partition.*
```solidity
function authorizeOperatorByPartition(bytes32 partition, address operator) external override;
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ----------------------------------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `operator` | `address` | Address to set as an operator for 'msg.sender'. |
#### revokeOperatorByPartition
*Remove the right of the operator address to be an operator on a given partition for 'msg.sender' and to transfer and redeem tokens on its behalf.*
```solidity
function revokeOperatorByPartition(bytes32 partition, address operator) external override;
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ---------------------------------------------------------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `operator` | `address` | Address to rescind as an operator on given partition for 'msg.sender'. |
#### isOperator
*Indicate whether the operator address is an operator of the tokenHolder address.*
```solidity
function isOperator(address operator, address tokenHolder) external view override returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | ----------------------------------------------------------------------------- |
| `operator` | `address` | Address which may be an operator of tokenHolder. |
| `tokenHolder` | `address` | Address of a token holder which may have the operator address as an operator. |
**Returns**
| Name | Type | Description |
| -------- | ------ | ------------------------------------------------------------------------- |
| `` | `bool` | 'true' if operator is an operator of 'tokenHolder' and 'false' otherwise. |
#### isOperatorForPartition
*Indicate whether the operator address is an operator of the tokenHolder address for the given partition.*
```solidity
function isOperatorForPartition(bytes32 partition, address operator, address tokenHolder)
external
view
override
returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | ----------------------------------------------------------------------------------------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `operator` | `address` | Address which may be an operator of tokenHolder for the given partition. |
| `tokenHolder` | `address` | Address of a token holder which may have the operator address as an operator for the given partition. |
**Returns**
| Name | Type | Description |
| -------- | ------ | ----------------------------------------------------------------------------------------------------- |
| `` | `bool` | 'true' if 'operator' is an operator of 'tokenHolder' for partition 'partition' and 'false' otherwise. |
#### isIssuable
*Know if new tokens can be issued in the future.*
```solidity
function isIssuable() external view override returns (bool);
```
**Returns**
| Name | Type | Description |
| -------- | ------ | --------------------------------------------------------------------------------------- |
| `` | `bool` | bool 'true' if tokens can still be issued by the issuer, 'false' if they can't anymore. |
#### issue
*Issue tokens from default partition.*
```solidity
function issue(address tokenHolder, uint256 value, bytes calldata data) external override onlyMinter isIssuableToken;
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | ---------------------------------------------------- |
| `tokenHolder` | `address` | Address for which we want to issue tokens. |
| `value` | `uint256` | Number of tokens issued. |
| `data` | `bytes` | Information attached to the issuance, by the issuer. |
#### issueByPartition
*Issue tokens from a specific partition.*
```solidity
function issueByPartition(bytes32 partition, address tokenHolder, uint256 value, bytes calldata data)
external
override
onlyMinter
isIssuableToken;
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | ---------------------------------------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `tokenHolder` | `address` | Address for which we want to issue tokens. |
| `value` | `uint256` | Number of tokens issued. |
| `data` | `bytes` | Information attached to the issuance, by the issuer. |
#### redeem
*Redeem the amount of tokens from the address 'msg.sender'.*
```solidity
function redeem(uint256 value, bytes calldata data) external override;
```
**Parameters**
| Name | Type | Description |
| ------- | --------- | ------------------------------------------------------------ |
| `value` | `uint256` | Number of tokens to redeem. |
| `data` | `bytes` | Information attached to the redemption, by the token holder. |
#### redeemFrom
*Redeem the amount of tokens on behalf of the address from.*
```solidity
function redeemFrom(address from, uint256 value, bytes calldata data) external virtual override;
```
**Parameters**
| Name | Type | Description |
| ------- | --------- | ------------------------------------------------------------------------------------- |
| `from` | `address` | Token holder whose tokens will be redeemed (or address(0) to set from to msg.sender). |
| `value` | `uint256` | Number of tokens to redeem. |
| `data` | `bytes` | Information attached to the redemption. |
#### redeemByPartition
*Redeem tokens of a specific partition.*
```solidity
function redeemByPartition(bytes32 partition, uint256 value, bytes calldata data) external override;
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | -------------------------------------------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `value` | `uint256` | Number of tokens redeemed. |
| `data` | `bytes` | Information attached to the redemption, by the redeemer. |
#### operatorRedeemByPartition
*Redeem tokens of a specific partition.*
```solidity
function operatorRedeemByPartition(bytes32 partition, address tokenHolder, uint256 value, bytes calldata operatorData)
external
override;
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | -------------------------------------------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `tokenHolder` | `address` | Address for which we want to redeem tokens. |
| `value` | `uint256` | Number of tokens redeemed |
| `operatorData` | `bytes` | Information attached to the redemption, by the operator. |
#### name
*Get the name of the token, e.g., "MyToken".*
```solidity
function name() external view returns (string memory);
```
**Returns**
| Name | Type | Description |
| -------- | -------- | ------------------ |
| `` | `string` | Name of the token. |
#### symbol
*Get the symbol of the token, e.g., "MYT".*
```solidity
function symbol() external view returns (string memory);
```
**Returns**
| Name | Type | Description |
| -------- | -------- | -------------------- |
| `` | `string` | Symbol of the token. |
#### decimals
*Get the number of decimals of the token.*
```solidity
function decimals() external pure returns (uint8);
```
**Returns**
| Name | Type | Description |
| -------- | ------- | -------------------------------------------------------------------------------------------------- |
| `` | `uint8` | The number of decimals of the token. For retrocompatibility, decimals are forced to 18 in ERC1400. |
#### granularity
*Get the smallest part of the token that’s not divisible.*
```solidity
function granularity() external view returns (uint256);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | --------------------------------------------- |
| `` | `uint256` | The smallest non-divisible part of the token. |
#### totalPartitions
*Get list of existing partitions.*
```solidity
function totalPartitions() external view returns (bytes32[] memory);
```
**Returns**
| Name | Type | Description |
| -------- | ----------- | ---------------------------------- |
| `` | `bytes32[]` | Array of all exisiting partitions. |
#### totalSupplyByPartition
*Get the total number of issued tokens for a given partition.*
```solidity
function totalSupplyByPartition(bytes32 partition) external view returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ---------------------- |
| `partition` | `bytes32` | Name of the partition. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------------------------------------------- |
| `` | `uint256` | Total supply of tokens currently in circulation, for a given partition. |
#### renounceControl
*Definitely renounce the possibility to control tokens on behalf of tokenHolders. Once set to false, '\_isControllable' can never be set to 'true' again.*
```solidity
function renounceControl() external onlyOwner;
```
#### renounceIssuance
*Definitely renounce the possibility to issue new tokens. Once set to false, '\_isIssuable' can never be set to 'true' again.*
```solidity
function renounceIssuance() external onlyOwner;
```
#### controllers
*Get the list of controllers as defined by the token contract.*
```solidity
function controllers() external view returns (address[] memory);
```
**Returns**
| Name | Type | Description |
| -------- | ----------- | ----------------------------------------- |
| `` | `address[]` | List of addresses of all the controllers. |
#### controllersByPartition
*Get controllers for a given partition.*
```solidity
function controllersByPartition(bytes32 partition) external view returns (address[] memory);
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ---------------------- |
| `partition` | `bytes32` | Name of the partition. |
**Returns**
| Name | Type | Description |
| -------- | ----------- | ----------------------------------- |
| `` | `address[]` | Array of controllers for partition. |
#### setControllers
*Set list of token controllers.*
```solidity
function setControllers(address[] calldata operators) external onlyOwner;
```
**Parameters**
| Name | Type | Description |
| ----------- | ----------- | --------------------- |
| `operators` | `address[]` | Controller addresses. |
#### setPartitionControllers
*Set list of token partition controllers.*
```solidity
function setPartitionControllers(bytes32 partition, address[] calldata operators) external onlyOwner;
```
**Parameters**
| Name | Type | Description |
| ----------- | ----------- | ---------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `operators` | `address[]` | Controller addresses. |
#### getDefaultPartitions
*Get default partitions to transfer from. Function used for ERC20 retrocompatibility. For example, a security token may return the bytes32("unrestricted").*
```solidity
function getDefaultPartitions() external view returns (bytes32[] memory);
```
**Returns**
| Name | Type | Description |
| -------- | ----------- | ---------------------------- |
| `` | `bytes32[]` | Array of default partitions. |
#### setDefaultPartitions
*Set default partitions to transfer from. Function used for ERC20 retrocompatibility.*
```solidity
function setDefaultPartitions(bytes32[] calldata partitions) external onlyOwner;
```
**Parameters**
| Name | Type | Description |
| ------------ | ----------- | ------------------------------------------------ |
| `partitions` | `bytes32[]` | partitions to use by default when not specified. |
#### allowanceByPartition
*Check the value of tokens that an owner allowed to a spender.*
```solidity
function allowanceByPartition(bytes32 partition, address owner, address spender)
external
view
override
returns (uint256);
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ----------------------------------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `owner` | `address` | address The address which owns the funds. |
| `spender` | `address` | address The address which will spend the funds. |
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------------------------------------------- |
| `` | `uint256` | A uint256 specifying the value of tokens still available for the spender. |
#### approveByPartition
*Approve the passed address to spend the specified amount of tokens on behalf of 'msg.sender'.*
```solidity
function approveByPartition(bytes32 partition, address spender, uint256 value) external returns (bool);
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | --------------------------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `spender` | `address` | The address which will spend the funds. |
| `value` | `uint256` | The amount of tokens to be spent. |
**Returns**
| Name | Type | Description |
| -------- | ------ | --------------------------------------------------------- |
| `` | `bool` | A boolean that indicates if the operation was successful. |
#### setTokenExtension
*Set token extension contract address. The extension contract can for example verify "ERC1400TokensValidator" or "ERC1400TokensChecker" interfaces. If the extension is an "ERC1400TokensValidator", it will be called everytime a transfer is executed.*
```solidity
function setTokenExtension(
address extension,
string calldata interfaceLabel,
bool removeOldExtensionRoles,
bool addMinterRoleForExtension,
bool addControllerRoleForExtension
) external onlyOwner;
```
**Parameters**
| Name | Type | Description |
| ------------------------------- | --------- | ----------------------------------------------------------------------------------------------- |
| `extension` | `address` | Address of the extension contract. |
| `interfaceLabel` | `string` | Interface label of extension contract. |
| `removeOldExtensionRoles` | `bool` | If set to 'true', the roles of the old extension(minter, controller) will be removed extension. |
| `addMinterRoleForExtension` | `bool` | If set to 'true', the extension contract will be added as minter. |
| `addControllerRoleForExtension` | `bool` | If set to 'true', the extension contract will be added as controller. |
#### migrate
\*Migrate contract. ===> CAUTION: DEFINITIVE ACTION This function shall be called once a new version of the smart contract has been created. Once this function is called:
* The address of the new smart contract is set in ERC1820 registry
* If the choice is definitive, the current smart contract is turned off and can never be used again\*
```solidity
function migrate(address newContractAddress, bool definitive) external onlyOwner;
```
**Parameters**
| Name | Type | Description |
| -------------------- | --------- | ------------------------------------------------------- |
| `newContractAddress` | `address` | Address of the new version of the smart contract. |
| `definitive` | `bool` | If set to 'true' the contract is turned off definitely. |
#### \_transferWithData
*Perform the transfer of tokens.*
```solidity
function _transferWithData(address from, address to, uint256 value) internal isNotMigratedToken;
```
**Parameters**
| Name | Type | Description |
| ------- | --------- | ----------------------------- |
| `from` | `address` | Token holder. |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens to transfer. |
#### \_transferByPartition
*Transfer tokens from a specific partition.*
```solidity
function _transferByPartition(
bytes32 fromPartition,
address operator,
address from,
address to,
uint256 value,
bytes memory data,
bytes memory operatorData
) internal returns (bytes32);
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | ------------------------------------------------------------------------------ |
| `fromPartition` | `bytes32` | Partition of the tokens to transfer. |
| `operator` | `address` | The address performing the transfer. |
| `from` | `address` | Token holder. |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens to transfer. |
| `data` | `bytes` | Information attached to the transfer. \[CAN CONTAIN THE DESTINATION PARTITION] |
| `operatorData` | `bytes` | Information attached to the transfer, by the operator (if any). |
**Returns**
| Name | Type | Description |
| -------- | --------- | ---------------------- |
| `` | `bytes32` | Destination partition. |
#### \_transferByDefaultPartitions
*Transfer tokens from default partitions. Function used for ERC20 retrocompatibility.*
```solidity
function _transferByDefaultPartitions(address operator, address from, address to, uint256 value, bytes memory data)
internal;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | -------------------------------------------------------------------------------------------------------------------------- |
| `operator` | `address` | The address performing the transfer. |
| `from` | `address` | Token holder. |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens to transfer. |
| `data` | `bytes` | Information attached to the transfer, and intended for the token holder ('from') \[CAN CONTAIN THE DESTINATION PARTITION]. |
#### \_getDestinationPartition
*Retrieve the destination partition from the 'data' field. By convention, a partition change is requested ONLY when 'data' starts with the flag: 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff When the flag is detected, the destination tranche is extracted from the 32 bytes following the flag.*
```solidity
function _getDestinationPartition(bytes32 fromPartition, bytes memory data)
internal
pure
returns (bytes32 toPartition);
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | ------------------------------------------------------------------------------ |
| `fromPartition` | `bytes32` | Partition of the tokens to transfer. |
| `data` | `bytes` | Information attached to the transfer. \[CAN CONTAIN THE DESTINATION PARTITION] |
**Returns**
| Name | Type | Description |
| ------------- | --------- | ---------------------- |
| `toPartition` | `bytes32` | Destination partition. |
#### \_removeTokenFromPartition
*Remove a token from a specific partition.*
```solidity
function _removeTokenFromPartition(address from, bytes32 partition, uint256 value) internal;
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ----------------------------- |
| `from` | `address` | Token holder. |
| `partition` | `bytes32` | Name of the partition. |
| `value` | `uint256` | Number of tokens to transfer. |
#### \_addTokenToPartition
*Add a token to a specific partition.*
```solidity
function _addTokenToPartition(address to, bytes32 partition, uint256 value) internal;
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ----------------------------- |
| `to` | `address` | Token recipient. |
| `partition` | `bytes32` | Name of the partition. |
| `value` | `uint256` | Number of tokens to transfer. |
#### \_isMultiple
*Check if 'value' is multiple of the granularity.*
```solidity
function _isMultiple(uint256 value) internal view returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------- | --------- | --------------------------------------- |
| `value` | `uint256` | The quantity that want's to be checked. |
**Returns**
| Name | Type | Description |
| -------- | ------ | --------------------------------------------------- |
| `` | `bool` | 'true' if 'value' is a multiple of the granularity. |
#### \_callSenderExtension
*Check for 'ERC1400TokensSender' user extension in ERC1820 registry and call it.*
```solidity
function _callSenderExtension(
bytes32 partition,
address operator,
address from,
address to,
uint256 value,
bytes memory data,
bytes memory operatorData
) internal;
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ------------------------------------------------------------------------------------------------ |
| `partition` | `bytes32` | Name of the partition (bytes32 to be left empty for transfers where partition is not specified). |
| `operator` | `address` | Address which triggered the balance decrease (through transfer or redemption). |
| `from` | `address` | Token holder. |
| `to` | `address` | Token recipient for a transfer and 0x for a redemption. |
| `value` | `uint256` | Number of tokens the token holder balance is decreased by. |
| `data` | `bytes` | Extra information. |
| `operatorData` | `bytes` | Extra information, attached by the operator (if any). |
#### \_callTokenExtension
*Check for 'ERC1400TokensValidator' token extension in ERC1820 registry and call it.*
```solidity
function _callTokenExtension(
bytes32 partition,
address operator,
address from,
address to,
uint256 value,
bytes memory data,
bytes memory operatorData
) internal;
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ------------------------------------------------------------------------------------------------ |
| `partition` | `bytes32` | Name of the partition (bytes32 to be left empty for transfers where partition is not specified). |
| `operator` | `address` | Address which triggered the balance decrease (through transfer or redemption). |
| `from` | `address` | Token holder. |
| `to` | `address` | Token recipient for a transfer and 0x for a redemption. |
| `value` | `uint256` | Number of tokens the token holder balance is decreased by. |
| `data` | `bytes` | Extra information. |
| `operatorData` | `bytes` | Extra information, attached by the operator (if any). |
#### \_callRecipientExtension
*Check for 'ERC1400TokensRecipient' user extension in ERC1820 registry and call it.*
```solidity
function _callRecipientExtension(
bytes32 partition,
address operator,
address from,
address to,
uint256 value,
bytes memory data,
bytes memory operatorData
) internal virtual;
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ------------------------------------------------------------------------------------------------ |
| `partition` | `bytes32` | Name of the partition (bytes32 to be left empty for transfers where partition is not specified). |
| `operator` | `address` | Address which triggered the balance increase (through transfer or issuance). |
| `from` | `address` | Token holder for a transfer and 0x for an issuance. |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens the recipient balance is increased by. |
| `data` | `bytes` | Extra information, intended for the token holder ('from'). |
| `operatorData` | `bytes` | Extra information attached by the operator (if any). |
#### \_isOperator
*Indicate whether the operator address is an operator of the tokenHolder address.*
```solidity
function _isOperator(address operator, address tokenHolder) internal view returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | ------------------------------------------------------------------------------- |
| `operator` | `address` | Address which may be an operator of 'tokenHolder'. |
| `tokenHolder` | `address` | Address of a token holder which may have the 'operator' address as an operator. |
**Returns**
| Name | Type | Description |
| -------- | ------ | --------------------------------------------------------------------------- |
| `` | `bool` | 'true' if 'operator' is an operator of 'tokenHolder' and 'false' otherwise. |
#### \_isOperatorForPartition
*Indicate whether the operator address is an operator of the tokenHolder address for the given partition.*
```solidity
function _isOperatorForPartition(bytes32 partition, address operator, address tokenHolder)
internal
view
returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | ----------------------------------------------------------------------------------------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `operator` | `address` | Address which may be an operator of tokenHolder for the given partition. |
| `tokenHolder` | `address` | Address of a token holder which may have the operator address as an operator for the given partition. |
**Returns**
| Name | Type | Description |
| -------- | ------ | ----------------------------------------------------------------------------------------------------- |
| `` | `bool` | 'true' if 'operator' is an operator of 'tokenHolder' for partition 'partition' and 'false' otherwise. |
#### \_issue
*Perform the issuance of tokens.*
```solidity
function _issue(address operator, address to, uint256 value, bytes memory data) internal isNotMigratedToken;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | -------------------------------------------------------------------------- |
| `operator` | `address` | Address which triggered the issuance. |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens issued. |
| `data` | `bytes` | Information attached to the issuance, and intended for the recipient (to). |
#### \_issueByPartition
*Issue tokens from a specific partition.*
```solidity
function _issueByPartition(bytes32 toPartition, address operator, address to, uint256 value, bytes memory data)
internal;
```
**Parameters**
| Name | Type | Description |
| ------------- | --------- | ------------------------------------- |
| `toPartition` | `bytes32` | Name of the partition. |
| `operator` | `address` | The address performing the issuance. |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens to issue. |
| `data` | `bytes` | Information attached to the issuance. |
#### \_redeem
*Perform the token redemption.*
```solidity
function _redeem(address operator, address from, uint256 value, bytes memory data) internal isNotMigratedToken;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ------------------------------------------- |
| `operator` | `address` | The address performing the redemption. |
| `from` | `address` | Token holder whose tokens will be redeemed. |
| `value` | `uint256` | Number of tokens to redeem. |
| `data` | `bytes` | Information attached to the redemption. |
#### \_redeemByPartition
*Redeem tokens of a specific partition.*
```solidity
function _redeemByPartition(
bytes32 fromPartition,
address operator,
address from,
uint256 value,
bytes memory data,
bytes memory operatorData
) internal;
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | ----------------------------------------------------------------- |
| `fromPartition` | `bytes32` | Name of the partition. |
| `operator` | `address` | The address performing the redemption. |
| `from` | `address` | Token holder whose tokens will be redeemed. |
| `value` | `uint256` | Number of tokens to redeem. |
| `data` | `bytes` | Information attached to the redemption. |
| `operatorData` | `bytes` | Information attached to the redemption, by the operator (if any). |
#### \_redeemByDefaultPartitions
*Redeem tokens from a default partitions.*
```solidity
function _redeemByDefaultPartitions(address operator, address from, uint256 value, bytes memory data) internal;
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | --------------------------------------- |
| `operator` | `address` | The address performing the redeem. |
| `from` | `address` | Token holder. |
| `value` | `uint256` | Number of tokens to redeem. |
| `data` | `bytes` | Information attached to the redemption. |
#### \_canTransfer
*Know the reason on success or failure based on the EIP-1066 application-specific status codes.*
```solidity
function _canTransfer(
bytes memory payload,
bytes32 partition,
address operator,
address from,
address to,
uint256 value,
bytes memory data,
bytes memory operatorData
) internal view returns (bytes1, bytes32, bytes32);
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ------------------------------------------------------------------------------ |
| `payload` | `bytes` | Payload of the initial transaction. |
| `partition` | `bytes32` | Name of the partition. |
| `operator` | `address` | The address performing the transfer. |
| `from` | `address` | Token holder. |
| `to` | `address` | Token recipient. |
| `value` | `uint256` | Number of tokens to transfer. |
| `data` | `bytes` | Information attached to the transfer. \[CAN CONTAIN THE DESTINATION PARTITION] |
| `operatorData` | `bytes` | Information attached to the transfer, by the operator (if any). |
**Returns**
| Name | Type | Description |
| -------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `` | `bytes1` | ESC (Ethereum Status Code) following the EIP-1066 standard. |
| `` | `bytes32` | Additional bytes32 parameter that can be used to define application specific reason codes with additional details (for example the transfer restriction rule responsible for making the transfer operation invalid). |
| `` | `bytes32` | Destination partition. |
#### \_setControllers
*Set list of token controllers.*
```solidity
function _setControllers(address[] memory operators) internal;
```
**Parameters**
| Name | Type | Description |
| ----------- | ----------- | --------------------- |
| `operators` | `address[]` | Controller addresses. |
#### \_setPartitionControllers
*Set list of token partition controllers.*
```solidity
function _setPartitionControllers(bytes32 partition, address[] memory operators) internal;
```
**Parameters**
| Name | Type | Description |
| ----------- | ----------- | ---------------------- |
| `partition` | `bytes32` | Name of the partition. |
| `operators` | `address[]` | Controller addresses. |
#### \_setTokenExtension
*Set token extension contract address. The extension contract can for example verify "ERC1400TokensValidator" or "ERC1400TokensChecker" interfaces. If the extension is an "ERC1400TokensValidator", it will be called everytime a transfer is executed.*
```solidity
function _setTokenExtension(
address extension,
string memory interfaceLabel,
bool removeOldExtensionRoles,
bool addMinterRoleForExtension,
bool addControllerRoleForExtension
) internal;
```
**Parameters**
| Name | Type | Description |
| ------------------------------- | --------- | ----------------------------------------------------------------------------------------------- |
| `extension` | `address` | Address of the extension contract. |
| `interfaceLabel` | `string` | Interface label of extension contract. |
| `removeOldExtensionRoles` | `bool` | If set to 'true', the roles of the old extension(minter, controller) will be removed extension. |
| `addMinterRoleForExtension` | `bool` | If set to 'true', the extension contract will be added as minter. |
| `addControllerRoleForExtension` | `bool` | If set to 'true', the extension contract will be added as controller. |
#### \_migrate
\*Migrate contract. ===> CAUTION: DEFINITIVE ACTION This function shall be called once a new version of the smart contract has been created. Once this function is called:
* The address of the new smart contract is set in ERC1820 registry
* If the choice is definitive, the current smart contract is turned off and can never be used again\*
```solidity
function _migrate(address newContractAddress, bool definitive) internal;
```
**Parameters**
| Name | Type | Description |
| -------------------- | --------- | ------------------------------------------------------- |
| `newContractAddress` | `address` | Address of the new version of the smart contract. |
| `definitive` | `bool` | If set to 'true' the contract is turned off definitely. |
#### domainName
```solidity
function domainName() public view override returns (string memory);
```
#### domainVersion
```solidity
function domainVersion() public pure override returns (string memory);
```
### Events
#### ApprovalByPartition
```solidity
event ApprovalByPartition(bytes32 indexed partition, address indexed owner, address indexed spender, uint256 value);
```
# SecurityToken.sol
## SecurityToken
[Git Source](https://github.com/Libertum-Project/security-token-contracts/blob/3464d5ab8850f3f8fc835299f95703c8793378ae/src\token\SecurityToken.sol)
**Inherits:** ERC1400HoldableTokenUpgradeable, ISecurityToken, MulticallUpgradeable, AccessManagedUpgradeable
Implementation of a security token using the ERC1400 standard
*This contract extends ERC1400HoldableTokenUpgradeable and implements ISecurityToken*
### Functions
#### constructor
*Disables initialization of the implementation contract*
```solidity
constructor();
```
#### initializeAuthority
*See {ISecurityToken-initializeAuthority}*
```solidity
function initializeAuthority(address initialAuthority) external initializer;
```
#### initialize
*See ISecurityToken-initialize*
```solidity
function initialize(InitializeParams calldata params) external override reinitializer(2);
```
#### delegate
```solidity
function delegate(address delegatee) public;
```
# ISecurityToken.sol
## ISecurityToken
[Git Source](https://github.com/Libertum-Project/security-token-contracts/blob/3464d5ab8850f3f8fc835299f95703c8793378ae/src\token\ISecurityToken.sol)
Interface for the SecurityToken contract
*Defines the structure and behavior for SecurityToken implementations*
### Functions
#### initializeAuthority
Initializes the authority for the SecurityToken
*This function should be called before the main initialize function*
```solidity
function initializeAuthority(address initialAuthority) external;
```
**Parameters**
| Name | Type | Description |
| ------------------ | --------- | ---------------------------------------------- |
| `initialAuthority` | `address` | The address to be set as the initial authority |
#### initialize
Initializes the SecurityToken with given parameters
*This function should be called immediately after deployment*
```solidity
function initialize(InitializeParams calldata params) external;
```
**Parameters**
| Name | Type | Description |
| -------- | ------------------ | ----------------------------------------------- |
| `params` | `InitializeParams` | Struct containing all initialization parameters |
### Structs
#### InitializeParams
Struct containing parameters for initializing a SecurityToken
*Used in the initialize function to set up the token*
```solidity
struct InitializeParams {
string name;
string symbol;
uint256 granularity;
address[] controllers;
bytes32[] defaultPartitions;
address extension;
address owner;
address minter;
}
```
# SecurityTokenFactory.sol
## SecurityTokenFactory
[Git Source](https://github.com/Libertum-Project/security-token-contracts/blob/3464d5ab8850f3f8fc835299f95703c8793378ae/src\token\factory\SecurityTokenFactory.sol)
**Inherits:** ISecurityTokenFactory, SecurityTokenFactoryStorage, AccessManagedUpgradeable
Factory contract for deploying and managing SecurityToken instances
*Uses the UpgradeableBeacon pattern for upgradeable proxy deployments*
*See {ISecurityTokenFactory}*
### Functions
#### initialize
*See ISecurityTokenFactory-initialize*
```solidity
function initialize(address initialAuthority, address initialImplementation) external initializer;
```
#### getDeploymentAddress
*See {ISecurityTokenFactory-getDeploymentAddress}*
```solidity
function getDeploymentAddress(bytes32 id) public view returns (address);
```
#### deploy
*See ISecurityTokenFactory-deploy*
```solidity
function deploy(bytes32 id, bytes calldata initData) external restricted returns (address deployment);
```
#### upgradeImplementation
*See {ISecurityTokenFactory-upgradeImplementation}*
```solidity
function upgradeImplementation(address newImplementation) external restricted;
```
#### beacon
*See {ISecurityTokenFactory-beacon}*
```solidity
function beacon() public view override returns (address);
```
#### implementation
*See ISecurityTokenFactory-implementation*
```solidity
function implementation() public view override returns (address);
```
# ISecurityTokenFactory.sol
## ISecurityTokenFactory
[Git Source](https://github.com/Libertum-Project/security-token-contracts/blob/3464d5ab8850f3f8fc835299f95703c8793378ae/src\token\factory\ISecurityTokenFactory.sol)
Interface for the SecurityTokenFactory contract
*Defines the structure for deploying and managing SecurityToken instances*
### Functions
#### initialize
Initializes the SecurityTokenFactory
*Sets up initial roles and deploys the UpgradeableBeacon*
```solidity
function initialize(address initialAuthority, address initialImplementation) external;
```
**Parameters**
| Name | Type | Description |
| ----------------------- | --------- | ------------------------------------------------------------ |
| `initialAuthority` | `address` | Address of the initial admin |
| `initialImplementation` | `address` | Address of the initial SecurityToken implementation contract |
#### getDeploymentAddress
Returns the deterministic deployment address for a given id
```solidity
function getDeploymentAddress(bytes32 id) external view returns (address);
```
**Parameters**
| Name | Type | Description |
| ---- | --------- | ------------------------------------ |
| `id` | `bytes32` | Unique identifier for the deployment |
**Returns**
| Name | Type | Description |
| -------- | --------- | -------------------------------------------------------------- |
| `` | `address` | The computed address where the SecurityToken would be deployed |
#### deploy
Deploys a new SecurityToken instance
*Uses Create2 for deterministic address generation*
```solidity
function deploy(bytes32 id, bytes calldata initData) external returns (address deployment);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | ------------------------------------------------------ |
| `id` | `bytes32` | Unique identifier for the deployment |
| `initData` | `bytes` | Initialization data for the new SecurityToken instance |
**Returns**
| Name | Type | Description |
| ------------ | --------- | ---------------------------------------------------- |
| `deployment` | `address` | Address of the newly deployed SecurityToken instance |
#### upgradeImplementation
Upgrades the implementation of all deployed SecurityToken instances
*Can only be called by addresses with the UPGRADE\_ROLE*
```solidity
function upgradeImplementation(address newImplementation) external;
```
**Parameters**
| Name | Type | Description |
| ------------------- | --------- | ------------------------------------------ |
| `newImplementation` | `address` | Address of the new implementation contract |
#### beacon
Returns the address of the SecurityTokenBeacon
```solidity
function beacon() external view returns (address);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ---------------------------------- |
| `` | `address` | Address of the SecurityTokenBeacon |
#### implementation
Returns the address of the current SecurityToken implementation
```solidity
function implementation() external view returns (address);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ------------------------------------- |
| `` | `address` | Address of the current implementation |
### Events
#### SecurityTokenDeployed
Emitted when a new SecurityToken is deployed
```solidity
event SecurityTokenDeployed(address indexed token);
```
**Parameters**
| Name | Type | Description |
| ------- | --------- | ------------------------------------------- |
| `token` | `address` | Address of the newly deployed SecurityToken |
#### ImplementationUpgraded
Emitted when the implementation is upgraded
```solidity
event ImplementationUpgraded(address indexed oldImplementation, address indexed newImplementation);
```
**Parameters**
| Name | Type | Description |
| ------------------- | --------- | -------------------------------------- |
| `oldImplementation` | `address` | Address of the previous implementation |
| `newImplementation` | `address` | Address of the new implementation |
# Position Manager
## Position Manager
### Introduction
The Position Manager system is designed to manage positions for security tokens. It allows users to create, manage, and trade tokenized positions that represent ownership of underlying security tokens. This system enhances the flexibility and functionality of security token ownership by introducing an ERC721-based wrapper around ERC1400 security tokens.
### Key Components
#### SecurityTokenPositionManager
The main contract responsible for creating and managing positions. It implements the ERC721 standard, allowing positions to be represented as unique, non-fungible tokens.
#### SecurityTokenPositionManagerFactory
A factory contract that deploys new instances of the SecurityTokenPositionManager. It uses the upgradeable beacon pattern for easy upgrades of all deployed instances.
#### ISecurityTokenPositionManager
The interface defining the core functionality of the Position Manager system.
### Functionality
#### Position Creation (Minting)
Users can create new positions by minting tokens through the SecurityTokenPositionManager. This process involves:
1. Approving the Position Manager to spend the user's security tokens.
2. Calling the `mint` function, specifying the security token address, amount, and recipient.
#### Position Liquidation (Burning)
Positions can be liquidated by burning the corresponding ERC721 token. This process:
1. Destroys the ERC721 token.
2. Transfers the underlying security tokens to a specified recipient.
#### Delegation
The Position Manager supports delegating voting power associated with the underlying security tokens.
### Usage Guide
#### Deploying a Position Manager
1. Deploy the SecurityTokenPositionManagerFactory.
2. Call the `deploy` function on the factory, providing initialization parameters:
* Name and symbol for the ERC721 token
* Owner address
```solidity
bytes32 pmId = keccak256("myPositionManager");
bytes memory pmInitData = abi.encodeWithSelector(
SecurityTokenPositionManager.initialize.selector,
"My Position Manager",
"MPM",
ownerAddress
);
address deployedPositionManager = pmFactory.deploy(pmId, pmInitData);
```
#### Creating a Position
1. Approve the Position Manager to spend your security tokens:
```solidity
securityToken.approve(positionManagerAddress, amount);
```
2. Mint a new position:
```solidity
uint256 tokenId = positionManager.mint(securityTokenAddress, amount, recipientAddress, "");
```
#### Liquidating a Position
To burn a position and receive the underlying security tokens:
```solidity
positionManager.burn(tokenId, recipientAddress);
```
#### Delegating Voting Power
To delegate the voting power associated with a position:
```solidity
positionManager.setDelegate(tokenId, delegateAddress);
```
#### Managing Security Tokens
As the contract owner, you can update or remove security token details:
```solidity
// Update
ISecurityTokenPositionManager.SecurityTokenDetails memory details =
ISecurityTokenPositionManager.SecurityTokenDetails({data: abi.encode("Updated details")});
positionManager.updateSecurityToken(securityTokenAddress, details);
// Remove
positionManager.removeSecurityToken(securityTokenAddress);
```
### Security Considerations
1. **Access Control**: Ensure that only authorized addresses can call sensitive functions like `updateSecurityToken` and `removeSecurityToken`.
2. **Token Approval**: Users must approve the Position Manager to spend their security tokens before minting. Always verify that approvals are set correctly.
3. **Upgrades**: The upgradeable beacon pattern allows for upgrades. Ensure that upgrade processes are secure and well-tested.
4. **Delegation**: Be aware that delegating voting power affects governance rights. Implement appropriate checks in any connected governance systems.
# SecurityTokenPositionManager.sol
## SecurityTokenPositionManager
[Git Source](https://github.com/Libertum-Project/security-token-contracts/blob/3464d5ab8850f3f8fc835299f95703c8793378ae/src\position\SecurityTokenPositionManager.sol)
**Inherits:** ISecurityTokenPositionManager, ISecurityTokenPositionManagerErrors, ERC721DescribableUpgradeable, ERC721TotalSupplyUpgradeable, SecurityTokenPositionManagerStorage, ERC721RoyaltyUpgradeable, MulticallUpgradeable, AccessManagedUpgradeable
Manages positions for security tokens, allowing minting, burning, and delegation of positions
*Implements ERC721 for position tokenization and includes royalty functionality*
### Functions
#### initializeAuthority
Initializes the authority for the position manager
*This function should only be called once, typically during contract deployment*
```solidity
function initializeAuthority(address initialAuthority) external override initializer;
```
**Parameters**
| Name | Type | Description |
| ------------------ | --------- | ---------------------------------------------- |
| `initialAuthority` | `address` | The address to be set as the initial authority |
#### initialize
Initializes the position manager and its associated ERC721 token
```solidity
function initialize(string calldata name, string calldata symbol, address descriptor) external reinitializer(2);
```
**Parameters**
| Name | Type | Description |
| ------------ | --------- | ------------------------------------------------------ |
| `name` | `string` | The name for the ERC721 token representing positions |
| `symbol` | `string` | The symbol for the ERC721 token representing positions |
| `descriptor` | `address` | The address of the descriptor contract |
#### updateSecurityToken
Updates the details of a security token
```solidity
function updateSecurityToken(address securityToken, SecurityTokenDetails calldata details)
external
override
restricted;
```
**Parameters**
| Name | Type | Description |
| --------------- | ---------------------- | ------------------------------------------- |
| `securityToken` | `address` | The address of the security token to update |
| `details` | `SecurityTokenDetails` | The new details for the security token |
#### removeSecurityToken
Removes a security token from the position manager
```solidity
function removeSecurityToken(address securityToken) external override restricted;
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | ------------------------------------------- |
| `securityToken` | `address` | The address of the security token to remove |
#### setDefaultRoyalty
Sets the default royalty for the contract
```solidity
function setDefaultRoyalty(address receiver, uint96 feeNumerator) external override restricted;
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ------------------------------------------- |
| `receiver` | `address` | The address to receive royalties |
| `feeNumerator` | `uint96` | The fee numerator for calculating royalties |
#### setTokenRoyalty
Sets the royalty for a specific token
```solidity
function setTokenRoyalty(uint256 tokenId, address receiver, uint96 feeNumerator) external override restricted;
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ------------------------------------------- |
| `tokenId` | `uint256` | The ID of the token to set royalties for |
| `receiver` | `address` | The address to receive royalties |
| `feeNumerator` | `uint96` | The fee numerator for calculating royalties |
#### mint
Mints a new position token representing a locked amount of security tokens
```solidity
function mint(address securityToken, uint256 amount, address recipient, bytes memory data)
external
override
returns (uint256 tokenId);
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | -------------------------------------------------------------- |
| `securityToken` | `address` | The address of the security token to be locked in the position |
| `amount` | `uint256` | The amount of security tokens to be locked in the position |
| `recipient` | `address` | The address to receive the minted position token |
| `data` | `bytes` | Additional data for the mint operation |
**Returns**
| Name | Type | Description |
| --------- | --------- | ----------------------------------------- |
| `tokenId` | `uint256` | The ID of the newly minted position token |
#### burn
Burns a position and releases the locked security tokens
```solidity
function burn(uint256 tokenId, address recipient) external override returns (TokenData memory data);
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ----------------------------------------------------- |
| `tokenId` | `uint256` | The ID of the position to burn |
| `recipient` | `address` | The address to receive the underlying security tokens |
**Returns**
| Name | Type | Description |
| ------ | ----------- | ------------------------------------ |
| `data` | `TokenData` | The TokenData of the burned position |
#### setDelegate
Sets the delegate for a position's voting power
```solidity
function setDelegate(uint256 tokenId, address target) external override;
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ------------------------------- |
| `tokenId` | `uint256` | The ID of the position token |
| `target` | `address` | The address of the new delegate |
#### securityTokenDetails
Retrieves the details of a security token
```solidity
function securityTokenDetails(address securityToken) public view override returns (SecurityTokenDetails memory);
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | --------------------------------- |
| `securityToken` | `address` | The address of the security token |
**Returns**
| Name | Type | Description |
| -------- | ---------------------- | -------------------------------------------------------- |
| `` | `SecurityTokenDetails` | The SecurityTokenDetails of the specified security token |
#### supportsInterface
Checks if the contract supports a given interface
```solidity
function supportsInterface(bytes4 interfaceId)
public
view
virtual
override(ERC721Upgradeable, ERC721DescribableUpgradeable, ERC721RoyaltyUpgradeable)
returns (bool);
```
**Parameters**
| Name | Type | Description |
| ------------- | -------- | --------------------------------- |
| `interfaceId` | `bytes4` | The interface identifier to check |
**Returns**
| Name | Type | Description |
| -------- | ------ | ----------------------------------------------------------------- |
| `` | `bool` | bool True if the contract supports the interface, false otherwise |
#### tokenURI
Returns the URI for a given token
```solidity
function tokenURI(uint256 tokenId)
public
view
virtual
override(ERC721Upgradeable, ERC721DescribableUpgradeable)
returns (string memory);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ------------------- |
| `tokenId` | `uint256` | The ID of the token |
**Returns**
| Name | Type | Description |
| -------- | -------- | --------------------------- |
| `` | `string` | string The URI of the token |
#### tokenData
Retrieves the token data for a position
```solidity
function tokenData(uint256 tokenId) public view override returns (TokenData memory);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ---------------------------- |
| `tokenId` | `uint256` | The ID of the position token |
**Returns**
| Name | Type | Description |
| -------- | ----------- | --------------------------------------- |
| `` | `TokenData` | The TokenData of the specified position |
#### \_update
*Internal function to update token ownership and delegate voting power*
```solidity
function _update(address to, uint256 tokenId, address auth)
internal
virtual
override(ERC721TotalSupplyUpgradeable, ERC721Upgradeable)
returns (address);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ------------------------------------------- |
| `to` | `address` | The address to transfer ownership to |
| `tokenId` | `uint256` | The ID of the token being transferred |
| `auth` | `address` | The address authorized to make the transfer |
**Returns**
| Name | Type | Description |
| -------- | --------- | --------------------------------------- |
| `` | `address` | address The previous owner of the token |
#### \_tokenURIData
*Internal function to retrieve and encode token and security token data*
```solidity
function _tokenURIData(uint256 tokenId) internal view virtual override returns (bytes memory);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ------------------- |
| `tokenId` | `uint256` | The ID of the token |
**Returns**
| Name | Type | Description |
| -------- | ------- | ---------------------------------------------------------------------- |
| `` | `bytes` | bytes The ABI-encoded token data and associated security token details |
# ISecurityTokenPositionManager.sol
## ISecurityTokenPositionManager
[Git Source](https://github.com/Libertum-Project/security-token-contracts/blob/3464d5ab8850f3f8fc835299f95703c8793378ae/src\position\ISecurityTokenPositionManager.sol)
Interface for managing positions in security tokens
*This interface defines the core functionality for minting, burning, and managing security token positions*
### Functions
#### initializeAuthority
Initializes the authority for the position manager
*This function should only be called once, typically during contract deployment*
```solidity
function initializeAuthority(address initialAuthority) external;
```
**Parameters**
| Name | Type | Description |
| ------------------ | --------- | ---------------------------------------------- |
| `initialAuthority` | `address` | The address to be set as the initial authority |
#### initialize
Initializes the position manager and its associated ERC721 token
```solidity
function initialize(string calldata name, string calldata symbol, address descriptor) external;
```
**Parameters**
| Name | Type | Description |
| ------------ | --------- | ------------------------------------------------------ |
| `name` | `string` | The name for the ERC721 token representing positions |
| `symbol` | `string` | The symbol for the ERC721 token representing positions |
| `descriptor` | `address` | The address of the descriptor contract |
#### updateSecurityToken
Updates the details of a security token
```solidity
function updateSecurityToken(address securityToken, SecurityTokenDetails calldata details) external;
```
**Parameters**
| Name | Type | Description |
| --------------- | ---------------------- | ------------------------------------------- |
| `securityToken` | `address` | The address of the security token to update |
| `details` | `SecurityTokenDetails` | The new details for the security token |
#### removeSecurityToken
Removes a security token from the position manager
```solidity
function removeSecurityToken(address securityToken) external;
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | ------------------------------------------- |
| `securityToken` | `address` | The address of the security token to remove |
#### setDefaultRoyalty
Sets the default royalty for the contract
```solidity
function setDefaultRoyalty(address receiver, uint96 feeNumerator) external;
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ------------------------------------------- |
| `receiver` | `address` | The address to receive royalties |
| `feeNumerator` | `uint96` | The fee numerator for calculating royalties |
#### setTokenRoyalty
Sets the royalty for a specific token
```solidity
function setTokenRoyalty(uint256 tokenId, address receiver, uint96 feeNumerator) external;
```
**Parameters**
| Name | Type | Description |
| -------------- | --------- | ------------------------------------------- |
| `tokenId` | `uint256` | The ID of the token to set royalties for |
| `receiver` | `address` | The address to receive royalties |
| `feeNumerator` | `uint96` | The fee numerator for calculating royalties |
#### mint
Mints a new position token representing a locked amount of security tokens
```solidity
function mint(address securityToken, uint256 amount, address recipient, bytes memory data)
external
returns (uint256 tokenId);
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | -------------------------------------------------------------- |
| `securityToken` | `address` | The address of the security token to be locked in the position |
| `amount` | `uint256` | The amount of security tokens to be locked in the position |
| `recipient` | `address` | The address to receive the minted position token |
| `data` | `bytes` | Additional data for the mint operation |
**Returns**
| Name | Type | Description |
| --------- | --------- | ----------------------------------------- |
| `tokenId` | `uint256` | The ID of the newly minted position token |
#### burn
Burns a position and releases the locked security tokens
```solidity
function burn(uint256 tokenId, address recipient) external returns (TokenData memory data);
```
**Parameters**
| Name | Type | Description |
| ----------- | --------- | ----------------------------------------------------- |
| `tokenId` | `uint256` | The ID of the position to burn |
| `recipient` | `address` | The address to receive the underlying security tokens |
**Returns**
| Name | Type | Description |
| ------ | ----------- | ------------------------------------ |
| `data` | `TokenData` | The TokenData of the burned position |
#### setDelegate
Sets the delegate for a position's voting power
```solidity
function setDelegate(uint256 tokenId, address target) external;
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ------------------------------- |
| `tokenId` | `uint256` | The ID of the position token |
| `target` | `address` | The address of the new delegate |
#### securityTokenDetails
Retrieves the details of a security token
```solidity
function securityTokenDetails(address securityToken) external view returns (SecurityTokenDetails memory);
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | --------------------------------- |
| `securityToken` | `address` | The address of the security token |
**Returns**
| Name | Type | Description |
| -------- | ---------------------- | -------------------------------------------------------- |
| `` | `SecurityTokenDetails` | The SecurityTokenDetails of the specified security token |
#### tokenData
Retrieves the token data for a position
```solidity
function tokenData(uint256 tokenId) external view returns (TokenData memory);
```
**Parameters**
| Name | Type | Description |
| --------- | --------- | ---------------------------- |
| `tokenId` | `uint256` | The ID of the position token |
**Returns**
| Name | Type | Description |
| -------- | ----------- | --------------------------------------- |
| `` | `TokenData` | The TokenData of the specified position |
### Events
#### Mint
Emitted when a new position is minted
```solidity
event Mint(
uint256 indexed tokenId,
address indexed securityToken,
uint256 indexed amount,
address container,
address recipient,
address sender
);
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | -------------------------------------------- |
| `tokenId` | `uint256` | The unique identifier of the minted position |
| `securityToken` | `address` | The address of the security token |
| `amount` | `uint256` | The amount of tokens in the position |
| `container` | `address` | The address of the votes container |
| `recipient` | `address` | The address receiving the minted position |
| `sender` | `address` | The address initiating the mint |
#### Burn
Emitted when a position is burned
```solidity
event Burn(
uint256 indexed tokenId, address indexed securityToken, uint256 indexed amount, address recipient, address sender
);
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | -------------------------------------------- |
| `tokenId` | `uint256` | The unique identifier of the burned position |
| `securityToken` | `address` | The address of the security token |
| `amount` | `uint256` | The amount of tokens in the burned position |
| `recipient` | `address` | The address receiving the underlying tokens |
| `sender` | `address` | The address initiating the burn |
#### UpdateSecurityToken
Emitted when a security token is updated
```solidity
event UpdateSecurityToken(address indexed securityToken);
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | ----------------------------------------- |
| `securityToken` | `address` | The address of the updated security token |
#### RemoveSecurityToken
Emitted when a security token is removed
```solidity
event RemoveSecurityToken(address indexed securityToken);
```
**Parameters**
| Name | Type | Description |
| --------------- | --------- | ----------------------------------------- |
| `securityToken` | `address` | The address of the removed security token |
### Structs
#### TokenData
Struct representing token data for a position
```solidity
struct TokenData {
address securityToken;
uint256 amount;
address container;
}
```
**Properties**
| Name | Type | Description |
| --------------- | --------- | ------------------------------------ |
| `securityToken` | `address` | The address of the security token |
| `amount` | `uint256` | The amount of tokens in the position |
| `container` | `address` | The address of the votes container |
#### SecurityTokenDetails
Struct representing details of a security token
```solidity
struct SecurityTokenDetails {
bytes data;
}
```
**Properties**
| Name | Type | Description |
| ------ | ------- | -------------------------------------------------- |
| `data` | `bytes` | Additional data associated with the security token |
# SecurityTokenPositionManagerFactory.sol
## SecurityTokenPositionManagerFactory
[Git Source](https://github.com/Libertum-Project/security-token-contracts/blob/3464d5ab8850f3f8fc835299f95703c8793378ae/src\position\factory\SecurityTokenPositionManagerFactory.sol)
**Inherits:** ISecurityTokenPositionManagerFactory, SecurityTokenPositionManagerFactoryStorage, AccessManagedUpgradeable
Factory contract for deploying and managing SecurityTokenPositionManager instances
*Uses the UpgradeableBeacon pattern for upgradeable proxy deployments*
### Functions
#### initialize
See ISecurityTokenPositionManagerFactory-initialize
```solidity
function initialize(address initialAuthority, address initialImplementation) external override initializer;
```
#### deploy
See ISecurityTokenPositionManagerFactory-deploy
```solidity
function deploy(bytes32 id, bytes calldata initData) external override restricted returns (address deployment);
```
#### upgradeImplementation
See ISecurityTokenPositionManagerFactory-upgradeImplementation
```solidity
function upgradeImplementation(address newImplementation) external override restricted;
```
#### getDeploymentAddress
See ISecurityTokenPositionManagerFactory-getDeploymentAddress
```solidity
function getDeploymentAddress(bytes32 id) public view returns (address);
```
#### beacon
See ISecurityTokenPositionManagerFactory-beacon
```solidity
function beacon() public view override returns (address);
```
#### implementation
See ISecurityTokenPositionManagerFactory-implementation
```solidity
function implementation() public view override returns (address);
```
# ISecurityTokenPositionManagerFactory.sol
## ISecurityTokenPositionManagerFactory
[Git Source](https://github.com/Libertum-Project/security-token-contracts/blob/3464d5ab8850f3f8fc835299f95703c8793378ae/src\position\factory\ISecurityTokenPositionManagerFactory.sol)
Interface for deploying and managing SecurityTokenPositionManager instances
### Functions
#### initialize
Initializes the factory contract
```solidity
function initialize(address initialAuthority, address initialImplementation) external;
```
**Parameters**
| Name | Type | Description |
| ----------------------- | --------- | ---------------------------------------------------------------------- |
| `initialAuthority` | `address` | The address to be granted admin rights |
| `initialImplementation` | `address` | The address of the initial SecurityTokenPositionManager implementation |
#### deploy
Deploys a new SecurityTokenPositionManager instance
```solidity
function deploy(bytes32 id, bytes calldata initData) external returns (address deployment);
```
**Parameters**
| Name | Type | Description |
| ---------- | --------- | --------------------------------------------------------------------- |
| `id` | `bytes32` | Unique identifier for the deployment |
| `initData` | `bytes` | Initialization data for the new SecurityTokenPositionManager instance |
**Returns**
| Name | Type | Description |
| ------------ | --------- | -------------------------------------------------------------- |
| `deployment` | `address` | The address of the newly deployed SecurityTokenPositionManager |
#### upgradeImplementation
Upgrades the implementation contract for all SecurityTokenPositionManager instances
```solidity
function upgradeImplementation(address newImplementation) external;
```
**Parameters**
| Name | Type | Description |
| ------------------- | --------- | ---------------------------------------------- |
| `newImplementation` | `address` | The address of the new implementation contract |
#### getDeploymentAddress
Computes the deployment address for a SecurityTokenPositionManager instance
```solidity
function getDeploymentAddress(bytes32 id) external view returns (address);
```
**Parameters**
| Name | Type | Description |
| ---- | --------- | ------------------------------------ |
| `id` | `bytes32` | Unique identifier for the deployment |
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------------------------------------------------- |
| `` | `address` | The computed address where the SecurityTokenPositionManager would be deployed |
#### beacon
Returns the address of the current beacon contract
```solidity
function beacon() external view returns (address);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ----------------------------------------------------- |
| `` | `address` | The address of the SecurityTokenPositionManagerBeacon |
#### implementation
Returns the address of the current implementation contract
```solidity
function implementation() external view returns (address);
```
**Returns**
| Name | Type | Description |
| -------- | --------- | ---------------------------------------------------------------------- |
| `` | `address` | The address of the current SecurityTokenPositionManager implementation |
### Events
#### SecurityTokenPositionManagerDeployed
Emitted when a new SecurityTokenPositionManager is deployed
```solidity
event SecurityTokenPositionManagerDeployed(address indexed positionManager);
```
**Parameters**
| Name | Type | Description |
| ----------------- | --------- | -------------------------------------------------------------- |
| `positionManager` | `address` | The address of the newly deployed SecurityTokenPositionManager |
#### ImplementationUpgraded
Emitted when the implementation contract is upgraded
```solidity
event ImplementationUpgraded(address indexed oldImplementation, address indexed newImplementation);
```
**Parameters**
| Name | Type | Description |
| ------------------- | --------- | --------------------------------------------------- |
| `oldImplementation` | `address` | The address of the previous implementation contract |
| `newImplementation` | `address` | The address of the new implementation contract |
# Roadmap
The Libertum Roadmap
The Libertum roadmap outlines the strategic milestones and objectives the project aims to achieve from Q3 2024 through 2026. Here’s a detailed breakdown:
#### 🔸 Q3 2024
* **Libertum Market Launch:** The introduction of the primary marketplace for the Libertum ecosystem.
* **Lending Market Launch:** Deployment of the lending platform, providing opportunities for users to borrow and lend assets.
* **Ambassador Program Begins:** Initiation of a program to engage community members as ambassadors to promote Libertum.
* **IFPE Licence Application:** Submission for necessary regulatory licensing to ensure compliance and legitimacy.
* **Social Login and Account Abstraction:** Implementation of social login features and account abstraction to simplify user experience.
* **Regulatory Compliance:** Ensuring all operations meet necessary regulatory standards.
* **$LBM CEX Listing:** Listing the $LBM token on centralized exchanges.
* **Security Token Audits:** Conducting audits on security tokens to ensure platform integrity and user protection.
#### 🔸 Q4 2024
* **First Real Estate Tokenization:** Tokenization of real estate assets, marking a significant milestone in the platform's growth.
* **First Gems Tokenization – $20m Emeralds:** Tokenization of gems, with a focus on emeralds, expanding asset classes available on the platform.
* **Lending Market Integration with More Liquidity Providers:** Enhancing the lending market by integrating with additional liquidity providers.
* **Launch “View” Libertum Token Analytics and Staking Pools:** Introduction of advanced analytics for tokens and the establishment of staking pools.
* **Launch on CoinWeb Cross Chain Test Infrastructure:** Integrating and testing cross-chain functionalities via CoinWeb infrastructure.
* **Second CEX Listings:** Expanding the presence of $LBM by listing on additional centralized exchanges.
* **Launch of “Get” Liquidity and Swap Tool:** Deployment of a tool for liquidity management and asset swapping.
#### 🔸 Q1 2025
* **Farming Market Launch:** Launching a farming market to enable yield farming opportunities.
* **Launch “Choose” – Governance and Voting Protocol:** Introduction of a decentralized governance and voting protocol to empower community decision-making.
* **First Farming Yield Generating Asset Tokenization:** Tokenization of assets designed to generate yield through farming.
* **Secondary Market Supports 3rd Party Properties:** Expansion of the secondary market to support properties from third-party sources.
* **DASP Licence Approval:** Securing the Digital Asset Service Provider (DASP) license to enhance regulatory compliance.
* **Debit Card Integration:** Rolling out debit card services linked to the Libertum ecosystem for easier access to funds.
* **Marketplace v2 Launch:** An upgraded version of the Libertum marketplace with enhanced features.
#### 🔸 Q2 2025
* **Global Expansion:** Scaling operations to enter new markets and reach a global audience.
* **CEX Launches:** Further expansion of token listings on additional centralized exchanges.
* **Community-Owned Digital Nomad Properties:** Facilitating the ownership of digital nomad properties by the community.
* **Expand Blockchain Networks:** Broadening the network infrastructure to include more blockchains.
* **Gamification of Marketplace:** Introducing gamified elements to the marketplace to enhance user engagement and experience.
* **White-Labelled Solution for Real Estate Companies and RWA Partners:** Offering customizable, white-labeled solutions for real estate companies and Real-World Asset (RWA) partners.
#### 🔸 2026
* **Libertums AI Auto-Tokenization Platform:** Launching an AI-driven platform to automate the tokenization of assets.
* **Enhanced Token Utilities:** Expanding the utility and use cases of tokens within the ecosystem.
* **Launch Libertums Grant Scheme:** Establishing a grant program to support projects and innovations within the Libertum ecosystem.
* **Farming Market v2 Launch:** Release of the second version of the farming market with new features and enhancements.
* **Libertums AI Investment Strategy Tool:** Introduction of an AI-powered tool to assist users in formulating investment strategies.
# Education Corner
At Libertum, we prioritize the education and empowerment of our community.
{% embed url="" %}
Check out and follow our Medium Page to Keep up to date on our latest developments
{% endembed %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
# Licensing
# Bitcoin Service Provider License
Libertum Receives Bitcoin Service Provider License from El Salvador Government
FOR IMMEDIATE RELEASE
San Salvador, El Salvador — Libertum is proud to announce that it has received the Bitcoin Service Provider (BSP) license from the Central Reserve Bank of El Salvador. This licence is a significant milestone for Libertum, affirming its commitment to providing a fully licensed infrastructure for real-world assets and linked financial opportunities.
With this licence, Libertum is now officially authorised by the government of El Salvador to engage in Bitcoin-related transactions, further strengthening its position in the rapidly evolving cryptocurrency landscape. This development positions Libertum at the forefront of delivering secure and regulated Bitcoin services, offering increased confidence to cryptocurrency enthusiasts and investors alike.
"Our receipt of the BSP licence marks a major milestone in our mission to provide cutting-edge financial solutions through cryptocurrency," said Javvad Azam, CEO at Libertum. "We are dedicated to operating within the highest standards of regulatory compliance and transparency. This licence allows us to continue innovating and expanding our services while ensuring security and trust for our users."
In addition to the BSP licence, Libertum is also on track to receive the Digital Asset Service Provider License (PSAD) by Q1 2025. This forthcoming licence will enable Libertum to expand its offerings to include a broader range of digital asset services, further solidifying its reputation as a leader in the cryptocurrency sector.
Libertum's commitment to compliance and innovation demonstrates its role as a pioneer in the real-world asset space, supporting El Salvador's vision of becoming a global hub for cryptocurrency adoption and development.
For more information about Libertum and its services, please visit [www.libertum.io](http://www.libertum.io).
Media Contact: Libertum
About Libertum: Libertum offers a fully comprehensive, scalable, and licensed infrastructure tailored for real-world asset tokenization and access to new financial opportunities. Libertum offers a versatile tokenisation protocol alongside a licensed marketplace. This platform supports buying, selling, trading, and engaging with DeFi protocols such as farming and borrowing, all centred around RWAs and security tokens.
# Disclaimer
**Disclaimer**
This Disclaimer ("Disclaimer") governs your use of the Libertum platform ("Platform") and the LBM tokens issued by Libertum ("we," "us," or "our"). By accessing or using the Platform and engaging with KEI tokens, you agree to comply with this Disclaimer.
1. **General Information**: The information provided on the Platform, including but not limited to the content, materials, and resources, is for general informational purposes only. It does not constitute financial, investment, or legal advice. You should not rely on the information provided on the Platform for making any decisions.
2. **No Investment Recommendation**: The information provided on the Platform should not be construed as an endorsement, recommendation, or solicitation to invest in KEI tokens or any other cryptocurrencies. We do not provide any investment advice or make any claims regarding the potential profitability or suitability of KEI tokens for your specific circumstances.
3. **Affiliate Programs**: We may participate in affiliate programs and may earn commissions or referral fees when users engage with third-party products or services through links or promotional content provided on the Platform. However, the presence of affiliate programs does not affect our commitment to providing unbiased and accurate information.
4. **Third-Party Content**: The Platform may contain links to third-party websites, applications, or resources. We are not responsible for the accuracy, reliability, or completeness of any content or resources provided by third parties. Any reliance on third-party content is at your own risk, and we disclaim any liability for damages or losses arising from such reliance.
5. **Third-Party Services**: We may mention or recommend certain third-party services or products on the Platform. However, we do not endorse or guarantee the quality, suitability, or reliability of those services or products. Any engagement with third-party services or products is at your own discretion and risk.
6. **No Warranty**: The Platform and the information provided on it are provided on an "as-is" basis, without any warranties or representations, whether expressed or implied. We disclaim all warranties, including but not limited to warranties of accuracy, reliability, merchantability, and fitness for a particular purpose.
7. **Limitation of Liability**: To the maximum extent permitted by applicable law, we shall not be liable for any direct, indirect, incidental, consequential, or punitive damages arising out of or in connection with your use of the Platform or engagement with KEI tokens. This includes any damages resulting from errors, omissions, interruptions, or delays in the Platform's operation.
8. **Modification of Disclaimer**: We reserve the right to modify or update this Disclaimer at any time, with or without notice. It is your responsibility to review this Disclaimer periodically. By continuing to use the Platform and engage with KEI tokens, you agree to be bound by the updated Disclaimer.
## GitHub Integrations
You expressly acknowledge, covenant, and agree that your access to and use of the App is at your sole risk, and that the app is provided "as is" and "as available" without warranties of any kind, whether express or implied. To the fullest extent permissible pursuant to applicable law, we, our subsidiaries, affiliates, directors, shareholders, employees, team members, contractors, and licensors make no express warranties and hereby disclaim all implied warranties regarding the App and any part of it (including, without limitation, the site, any smart contract, or any external websites), including the implied warranties of merchantability, fitness for a particular purpose, non-infringement, correctness, accuracy, or reliability. Without limiting the generality of the foregoing, we, our subsidiaries, affiliates, directors, shareholders, employees, team members, contractors, and licensors do not represent or warrant to you that:
1. Your access to or use of the App will meet your requirements;
2. Your access to or use of the App will be uninterrupted, timely, secure or free from error;
3. Usage data provided through the App will be accurate;
4. The app or any content, services, or features made available on or through the App are free of viruses or other harmful components, or
5. That any data that you disclose when you use the App will be secure.
Some jurisdictions do not allow the exclusion of implied warranties in contracts with consumers, so some or all of the above exclusions may not apply to you. In any event, we exclude any and all implied warranties to the maximum extent permitted by law.
You accept the inherent security risks of providing information and dealing online over the internet, and acknowledge, covenant and agree that we have no liability or responsibility for any breach of security unless it is due to our gross negligence.
You acknowledge, covenant and agree that our product is a game of chance and you acknowledge the inherent risks involved in games of chance.
We will not be responsible or liable to you for any losses you incur as the result of your use of the Ethereum network, any other supported blockchain or any electronic wallet, including but not limited to any losses, damages or claims arising from:
1. User error, such as forgotten passwords or incorrectly construed smart contracts or other transactions;
2. 6.4.2.Server failure or data loss;
3. 6.4.3.Corrupted wallet files; or
4. Unauthorised access or activities by third parties, including but not limited to the use of viruses, phishing, bruteforcing or other means of attack against the App, any supported blockchain, or any electronic wallet.
Cryptocurrency Tokens and NFTs are intangible digital assets that exist only by virtue of the ownership record maintained in a supported blockchain. All smart contracts are conducted and occur on the decentralised ledger within the supported blockchain platforms. We have no control over and make no guarantees or promises with respect to smart contracts.
Libertum is not responsible for losses due to blockchains or any other features of the Ethereum network, any other supported blockchain, or any electronic wallet, including but not limited to late report by developers or representatives (or no report at all) of any issues with the blockchain supporting the Ethereum network (or any other supported blockchain) including forks, technical node issues, or any other issues having fund losses as a result.
Libertum does not provide investment or financial advice or products. Libertum, its subsidiaries, affiliates, directors, shareholders, employees, team members, contractors, and licensors are not financial advisors. You should consider seeking independent legal, financial, and/or taxation or other advice in relation to your affairs. Always do your own research.
You further acknowledge covenant and agree that Libertum, its subsidiaries, affiliates, directors, shareholders, employees, team members, contractors, and licensors have not made any representations in relation to the following:
1. That the value of any Token or NFT purchased via our App will increase or appreciate in any manner;
2. That Libertum, its subsidiaries, affiliates, directors, shareholders, employees, team members, contractors, and licensors have the expertise or ability to grow the value of any Token purchased or otherwise acquired via the App.
While care and diligence have been used to maintain the information on the Libertum website and App, it may not be accurate, current or complete in all respects and, consequently, Libertum does not make any representations or warranties as to the accuracy, currency, or completeness of the information.
Libertum is not responsible to you or anyone else for any loss suffered in connection with the use of the Libertum App and website or any of its content. Libertum excludes, to the maximum extent permitted by law, any liability which may arise as a result of the use of the Kei Finance App (including the website, its content or the information on it, and links to other websites).
Where liability cannot be excluded, any liability incurred by us in relation to the use of the Kei Finance App or its content, is limited to the extent provided for by the local consumer laws. To the extent permitted by law, Libertum will not be liable for any consequential, incidental, indirect or special loss.
Libertum does not endorse any cryptocurrency or NFT projects. Any reference to cryptocurrency or NFT projects and partnerships on our website does not constitute an express, or implied endorsement by Libertum. Libertum is not liable for any loss caused, whether due to negligence or otherwise arising from the use of, or reliance on, the information provided directly or indirectly, by use of this website and app.
The linked sites included in this website are not under the control of Libertum and Libertum is not responsible for the content of any linked site or any link contained in a linked site, or changes or updates to such sites.
The included links do not expressly or implicitly suggest an endorsement by Libertum of the site or a relationship with the organisations to which links are provided.
# KYC
Libertum performs Know-Your-Customer and Know-Your-Business checks on lenders across the platform. These checks include:
* The collection of documentation and information to identify the user. In case of an Entity, the Ultimate Beneficial Owners and Directors are identified as well.
* Accreditation checks on Lenders.
* PEP and Sanction scans for all users.
* Lender wallets that hit on risks (including interaction with high risk counterparty wallets) are blocked.
For questions about KYC or legal agreements, please contact
# Privacy Policy
1. **PRIVACY POLICY**
Our Privacy Policy describes the ways we collect, use, store and disclose your personal information, and is hereby incorporated by this reference into these Terms and Conditions. You agree to the collection, use, storage, and disclosure of your data in accordance with our Privacy Policy.
We may collect and hold your personal and contact details, such as your IP address, your wallet address, metadata, cookies, and your App transaction information in order to monitor and improve the usage of the App and our website.
We do not use your personal information or disclose it to another organisation unless required or authorised by law or court or tribunal, or you have provided your consent, or the assets and operations of our business are transferred to another party as a going concern, or it is necessary to obtain third party services.
We take reasonable precautions to protect the personal information we hold from misuse, loss, unauthorised access, modification, or disclosure.
We collect personal information through software such as cookies.
This Privacy Policy does not apply to linked websites.
# Terms and Conditions
Please ensure you have read and understand our terms and conditions
Libertum is a decentralised finance (DeFi) application that interacts with the Ethereum network and Arbitrum network, accessed via a specially developed smart contract (“Smart Contract”) to enable users to access a swapping & bonding protocol, staking and lending functions, tooling and treasury management services (“Services). The protocol and its Services can be accessed on a website that the user can interact with (the “Site”). The swapping & bonding protocol, staking and lending functions and treasury management services, Smart Contract and the Site are collectively referred to in these Terms as the “App.” Using the App, users can interact with existing smart contracts on the Ethereum network in order to access the Services. Our App enables users to access DeFi Services that may be further developed by us in the future.
Libertum Ltd. a company incorporated in the UK (Registered Company Number: XXXXX) (hereinafter referred to as "Libertum", "we", or "us") is making the App available to you. Before you use the App, the Smart Contracts, or the Site, however, you will need to agree to these Terms of Use and any terms and conditions incorporated herein by reference (collectively, these "Terms").
Please read these terms and conditions carefully before using the App, the smart contracts, or the site. These terms govern your use of the App, the smart contracts, and the site, unless we have executed a separate written agreement with you for that purpose. We are only willing to make the App, the smart contracts, and the site available to you if you accept all of these terms. By using the App, the smart contracts, the site, or any part of them, you acknowledge, covenant, and agree that you understand and agree to be bound by all of these terms and conditions.
If you are accepting these terms on behalf of a company or other legal entity, you warrant, covenant, and agree that you have the legal authority to accept these terms on that entity’s behalf, in which case “you” will mean that entity. If you do not have such authority, or if you do not accept all of these terms and conditions, then we are unwilling to make the App, the smart contracts, or the site available to you. If you do not agree to these terms, you may not access or use the App, the smart contracts, or the site.
Upon acceptance of these terms and conditions, you further warrant, covenant, and agree that you are able to access the App, the Site, and the smart contract legally and in accordance with your local laws and regulations. We do not make any warranties or representations as to the compliance of the usage of our App and services with local laws and regulations. Upon acceptance of these terms and conditions, you hereby and irrevocably release Libertum, its directors, shareholders, employees, team members, and contractors from any and all present and future liability and claims in relation to any loss, penalties, fines, taxation assessments and proceedings arising from the usage of our App and services to the maximum extent permitted by law.
Dedicated and detailed information in relation to the protocol, the swapping, bonding, staking, lending and governance mechanisms can be found at the following link:[ https://docs.kei.fi/](https://docs.kei.fi/)
### TERMINATION
You may terminate these Terms and Conditions at any time by disposing of your Libertum Token(s) and/or NFT(s) and discontinuing your access to and use of the App. You will not receive any refunds if you dispose of your Libertum NFT(s), or otherwise terminate these Terms and Conditions. You covenant and agree that we, in our sole discretion and for any or no reason, may terminate these Terms and Conditions and suspend and/or terminate your access to the App.
You covenant and agree that any suspension or termination of your access to the App may be without prior notice, and that we will not be liable to you or to any third party for any such suspension or termination. If we terminate these Terms and Conditions or suspend or terminate your access to or use of the App due to your breach of these Terms and Conditions or any suspected fraudulent, abusive, or illegal activity, then termination of these Terms and Conditions will be in addition to any other remedies we may have at law or in equity.
Upon any termination or expiration of these Terms and Conditions, whether by you or us, you may no longer have access to information that you have obtained on the App, and you acknowledge, covenant and agree that we will have no obligation to maintain any such information in our databases or to forward any such information to you or to any third party.
Sections 1.3, 2, 3 through 16 will survive the termination or expiration of these Terms and Conditions for any reason.
### EXTERNAL SITE
The App may include hyperlinks to other websites or resources (collectively, “External Sites”), which are provided solely as a convenience to our users. We have no control over any External Sites. You acknowledge, covenant, and agree that we are not responsible for the availability of any External Sites, and that we do not endorse any advertising, products, or other materials on or made available from any External Sites.
Furthermore, you acknowledge, covenant, and agree that we are not liable for any loss or damage which may be incurred as a result of the availability or unavailability of the External Sites, or as a result of any reliance placed by you upon the completeness, accuracy or existence of any advertising, products or other materials on, or made available from, any External Sites. This Clause 10.1 operates in accordance with the disclaimer set out in Clause 6.9 above.
### AMENDMENTS OR CHANGES TO THESE TERMS AND CONDITIONS OF USE
We may make changes to the Terms and Conditions of Use from time to time. When we make changes, we will make the updated Terms and Conditions of Use available on the App and update the “Last Updated” date at the beginning of these Terms and Conditions accordingly. Please check these Terms and Conditions periodically for changes. Any changes to the Terms and Conditions will apply on the date that they are made, and your continued access to or use of the App after the Terms and Conditions have been updated will constitute your binding acceptance of the updates. If you do not agree to any revised Terms and Conditions, you may not access or use the App.
### CHANGES TO THE APP
We are constantly working on and innovating the App to help provide the best possible experience and services. You acknowledge, covenant, and agree that the form and nature of the App, and any part of it, may change from time to time without prior notice to you, and that we may add new features and change any part of the App at any time without notice.
### CHILDREN AND MINORS
You affirm that you are over the age of 18, as the App is not intended for persons under the age of 18. IF YOU ARE 18 OR OLDER BUT UNDER THE LEGAL AGE OF MAJORITY WHERE YOU RESIDE IF THAT JURISDICTION HAS AN OLDER AGE OF MAJORITY, THEN YOU AGREE TO REVIEW THESE TERMS AND CONDITIONS WITH YOUR PARENT OR GUARDIAN TO ENSURE THAT BOTH YOU AND YOUR PARENT OR GUARDIAN UNDERSTAND AND AGREE TO THESE TERMS AND CONDITIONS OF USE.YOU AGREE TO HAVE YOUR PARENT OR GUARDIAN REVIEW AND ACCEPT THESE TERMS ON YOUR BEHALF. IF YOU ARE A PARENT OR GUARDIAN AGREEING TO THE TERMS FOR THE BENEFIT OF A LEGALLY MINOR PERSON OVER 18, THEN YOU AGREE TO AND ACCEPT FULL RESPONSIBILITY FOR THAT PERSON'S USE OF THE APP, INCLUDING ALL FINANCIAL CHARGES AND LEGAL LIABILITY THAT HE OR SHE MAY INCUR.
### DISPUTE RESOLUTION AND ARBITRATION
Please read this Clause 15 carefully. It requires you to arbitrate disputes with Libertum and limits the manner in which you can seek relief from us.
All disputes against Libertum, its subsidiaries, affiliates, directors, shareholders officers, agents, employees, team members, advertisers, licensors, suppliers or partners arising out of or in connection with these Terms and Conditions, including without limitation your access or use of the App, or to any products provided, sold or distributed through the App will be referred to and finally resolved by arbitration under the rules of the UKJT Digital Dispute Resolution Rules. The appointing authority of the arbitrator will be an organisation operating under the said dispute resolution rules. You acknowledge, covenant, and agree that Libertum is solely entitled to nominate and refer the matter for arbitration to an arbitration organisation of Libertum's choice, subject to the said organisation adjudicating the matter in accordance with the said dispute resolution rules. The case will be adjudicated by a single arbitrator and will be administered by the appointing authority nominated by Libertum in accordance with its applicable rules.
Each party will cover its own fees and costs associated with the arbitration proceedings; however, if the arbitrator finds that you cannot afford to pay the fees and costs reasonably associated with the arbitration proceedings, Libertum will pay them for you. The place of arbitration will be chosen by the appointing authority. You may choose to have the arbitration conducted by written submissions only. The language of the arbitration will be English. The award of the arbitrator will be final and binding, and any judgement on the award rendered by the arbitrator may be entered in any court of competent jurisdiction. Notwithstanding the foregoing, Libertum may seek and obtain injunctive relief in any jurisdiction in any court of competent jurisdiction, and you agree that these Terms and Conditions are specifically enforceable by Libertum through injunctive relief and other equitable remedies without proof of monetary damages.
With respect to any dispute arising out of or related to these Terms and Conditions, including without limitation disputes related to the App, or any products provided, sold or distributed through the App:
You hereby expressly waive your right to have a trial by jury in the jurisdiction that it is applicable; and
You hereby expressly waive your right to participate as a member of a class of claimants in any lawsuit, including but not limited to class action lawsuits involving any such dispute.
### SERVICES NOT OFFERED IN CERTAIN JURISDICTIONS
You hereby acknowledge, covenant, and agree that we do not offer our services and do not carry-on business in the Republic of Panama, the Commonwealth of Australia, and the United States of America.
You further acknowledge, covenant and agree that users that are tax residents or located at the jurisdictions mentioned in clause 16.1 above are not allowed to access or use our app.
In the event that you breach this clause 16, you covenant and agree that we may suspend or terminate your access to our website and app without prior notice and you hereby irrevocably release in perpetuity Libertum, its subsidiaries, affiliates, directors, shareholders, employees, team members, contractors, and licensors from any and all losses, claims, damages, and liability that may arise from the suspension or termination of your access to our app as a result of breaching this clause 16.
You shall not purchase or otherwise acquire any of our NFTs and products if you are: a citizen, resident (tax or otherwise), and/or green card holder, incorporated in, owned or controlled by a person or entity in, located in, or have a registered office or principal place of business in the U.S. (defined as a U.S. person), or if you are a person in any jurisdiction in which such offer, sale, and/or purchase of any of our NFTs or products is unlawful, prohibited, or unauthorised (together with U.S. persons, a “Restricted Person”). The term “Restricted Person” includes, but is not limited to, any natural person residing in, or any firm, company, partnership, trust, corporation, entity, government, state or agency of a state, or any other incorporated or unincorporated body or association, association or partnership (whether or not having separate legal personality) that is established and/or lawfully existing under the laws of, a jurisdiction in which such offer, sale, and/or purchase of any of our products is unlawful, prohibited, or unauthorised). You shall not resell or otherwise transfer any of our products to any Restricted Person, including but not limited to, citizens, residents, or green card holders of the United States of America or any natural person or entity within the United States of America. The transfer or resale of any of our products to any Restricted Person is not permitted.
None of our products have been or will be registered under the U.S. Securities Act of 1933, as amended, or with any securities regulatory authority of any state or other jurisdiction of the U.S. Our products may not be offered, sold, or delivered within the U.S. to, or for the account or benefit of, Restricted Persons. Our products that may be offered on secondary markets and other platforms are not for distribution to any Restricted Person. No offers, sales, resales, or deliveries of any of our products may be made in or from any jurisdiction (including the U.S.), except in circumstances that will result in compliance with any applicable laws and regulations and that will not impose any obligations on Libertum. Persons who obtain our products are required to inform themselves about and adhere to any such restrictions. Libertum reserves the right to impose further restrictions at its sole discretion, which will be communicated through its terms of service or on its website.
You understand that Libertum is not registered or licensed by the Commodity Futures Trading Commission, Securities and Exchange Commission, Financial Crimes Enforcement Network, or any financial regulatory authority, and that no financial regulatory authority has reviewed or approved the website. You further understand that Libertum is not acting as an investment adviser or commodity trading adviser (as those terms are defined under U.S. law) to any person, does not offer securities services in the United States or to U.S. persons, and that the contents of this website do not constitute advice or recommendations concerning any commodity, security or other asset.
Additionally, no person may acquire Libertum Tokens, NFTs and products unless they are:
* not a “U.S. Person” as defined in Rule 902 of Regulation S promulgated under the Securities Act;
* not offering, trading or holding Libertum Tokens, NFTs or products for the account or benefit of any U.S. Person;
* not intending to sell, grant any participation in, or otherwise distribute Libertum Tokens, NFTs and products to any U.S. Person;
* not a “U.S. person” as defined in 17 C.F.R. § 23.23(a)(23) of the CFTC Cross-Border Swaps Rule;
* not acquiring Libertum assets for the account or benefit of any U.S. person;
* not intending to sell, grant any participation in, or otherwise distribute Libertum Tokens, NFTs or products to any U.S. Person; and
* Not intending to offer, sell, or distribute Libertum Tokens, NFTs or products or have a direct or indirect participation in any such undertaking or the underwriting of any such undertaking.
### THE APP
To use the App most easily, you may first install a web browser (such as the Google Chrome web browser) and an electronic wallet compatible with the erc-20 Token standard and Non-Fungible Token (NFT) standard on the Ethereum network, such as the MetaMask electronic wallet. MetaMask wallet and other electronic wallets allow you to purchase (either directly, or via other third-party sites), store, and engage in transactions using Ethereum cryptocurrency. You will not be able to engage in any transactions on the App other than through MetaMask wallet, or other Ethereum-compatible browsers and wallets as confirmed on our website and official social media platforms.
Transactions that take place on the App are managed and confirmed via the Ethereum blockchain and/or any other blockchain supported in the future. You acknowledge, covenant, and agree that your Ethereum public address will be made publicly visible whenever you engage in a transaction on the App.
We neither own nor control Metamask, any centralised or decentralised exchanges, Google Chrome, the Ethereum network, or any other third-party site, blockchain, product, or service that you might access, visit, or use for the purpose of enabling you to use the various features of the App. You acknowledge, covenant, and agree that we will not be liable for the acts or omissions of any such third parties, nor will we be liable for any damage that you may suffer as a result of your transactions or any other interaction with any such third parties.
You must connect your wallet in order to interact with and use the App. By connecting your wallet, you warrant, covenant, and agree that you are responsible for the security of your account and your MetaMask wallet (or any other electronic wallets and accounts). Libertum will never intentionally gain access to or store any private wallet keys. If you become aware of any unauthorised use of your wallet through our App or Site, you agree to notify us immediately at .
#### Feedback
You may choose to submit comments, bug reports, ideas, or other feedback about the App, including without limitation about how to improve the App (collectively, “Feedback”). By submitting any Feedback, you agree that we are free to use such Feedback at our discretion and without additional compensation to you, and to disclose such Feedback to third-parties (whether on a non-confidential basis, or otherwise). You hereby grant us a perpetual, irrevocable, nonexclusive, worldwide licence under all rights necessary for us to incorporate and use your Feedback for any purpose.
### LIMITATION OF LIABILITY
You acknowledge, covenant, and agree that we, our subsidiaries, affiliates, directors, shareholders, employees, team members, contractors, and licensors will not be liable to you or to any third-party for any indirect, incidental, special, consequential, or exemplary damages which you may incur, howsoever caused and under any theory of liability, including, without limitation, any loss of profits (whether incurred directly or indirectly), loss of goodwill or business reputation, loss of data, cost of procurement of substitute goods or services, or any other intangible loss, even if we have been advised of the possibility of such damages. You further covenant and agree that you release Libertum, our subsidiaries, affiliates, directors, shareholders, employees, team members, contractors, and licensors from any liability, damages, claim, or losses that may arise in accordance with this clause 7.1.
You acknowledge, covenant, and agree that our total, aggregate liability to you for any and all claims arising out of or relating to these terms or your access to or use of (or your inability to access or use) any portion of the App whether in contract, tort, strict liability, or any other legal theory, is limited to the greater of:
The amounts you actually paid us under these terms in the 12-month period preceding the date the claim arose; or
7.2.2.$100.
You acknowledge, covenant, and agree that we have made the App available to you and entered into these terms in reliance upon the warranties, disclaimers, and limitations of liability set forth herein, which reflect a reasonable and fair allocation of risk between the parties and form an essential basis of the bargain between us. You further acknowledge, covenant, and agree that we would not be able to provide the App to you without these limitations.
Some jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, and some jurisdictions also limit disclaimers or limitations of liability for personal injury from consumer products, so the above limitations may not apply to personal injury claims.
You hereby acknowledge, covenant, and agree that you release in perpetuity Libertum, its subsidiaries, affiliates, directors, shareholders, employees, team members, contractors, and licensors from any and all losses, claims, damages, and liability that may arise from the use of our App apart as it is set out in these Terms and Conditions of Use.
### ASSUMPTION OF RISK
You acknowledge, covenant, and agree as follows:
The prices of blockchain assets are extremely volatile. Fluctuations in the price of other digital assets could materially and adversely affect the value of your Libertum Tokens and NFTs, which may also be subject to significant price volatility. We cannot guarantee that any purchases made via our App will not lose money.
You are solely responsible for determining what, if any, taxes apply to your Libertum Token and NFT transactions related to our App. Libertum is not responsible for determining the taxes that apply to your transactions on the App, the Site, or any Smart Contract.
The App does not store, send, or receive Tokens or NFTs. This is because NFTs exist only by virtue of the ownership record maintained on the App’s supporting blockchain. Any transfer of NFT occurs within the supporting blockchain and not on the actual App.
There are risks associated with using an Internet-based currency, including but not limited to, the risk of hardware, software and Internet connections, the risk of malicious software introduction, and the risk that third parties may obtain unauthorised access to information stored within your wallet. You accept and acknowledge that Libertum will not be responsible for any communication failures, disruptions, errors, distortions or delays you may experience when using any supported blockchain, however caused.
A lack of use or public interest in the creation and development of distributed ecosystems could negatively impact the development of the Libertum ecosystem, and therefore the potential commercial viability, utility or value of our App and Libertum Tokens and NFTs.
The regulatory regime governing blockchain technologies, cryptocurrencies, and tokens is uncertain, and new regulations or policies may materially adversely affect the development of the Libertum ecosystem, and therefore the potential commercial viability, utility or value of our App and Libertum Tokens and NFTs.
Upgrades by Ethereum to the Ethereum platform, a hard fork in the Ethereum platform, or a change in how transactions are confirmed on the Ethereum platform may have unintended, adverse effects on all blockchains using the ERC-20 standard, including the Libertum ecosystem.
### INDEMNIFICATION
You covenant and agree to indemnify and hold harmless and indemnified Libertum and its subsidiaries, affiliates, directors, shareholders officers, agents, employees, team members, advertisers, licensors, suppliers or partners from and against any claim, liability, loss, damage (actual and consequential) of any kind or nature, suit, judgement, litigation cost, and legal fees arising out of or in any way related to:
* your breach of these Terms,
* your misuse of the App, or
* your violation of applicable laws, rules, or regulations in connection with your access to or use of the App.
You agree that Libertum will have control of the defence or settlement of any such claims.
### GENERAL PROVISIONS
These Terms and Conditions constitute the entire legal agreement between you and Libertum, govern your access to and use of the App and completely replace any prior or contemporaneous agreements between the parties in relation to your access to or use of the App, whether oral or written.
There are no third-party beneficiaries to these Terms and Conditions. The parties are independent contractors, and nothing in these Terms and Conditions create any agency, partnership, or joint venture.
The language in these Terms and Conditions will be interpreted as to its fair meaning, and not strictly for or against any party.
We may assign our rights and obligations under these Terms and Conditions in our sole discretion to an affiliate, or in connection with an acquisition, sale, or merger.
You may not assign any or your rights or obligations under these Terms and Conditions, whether by operation of law or otherwise, without our prior written consent.
Should any term or provision of these Terms and Conditions be held void, voidable, invalid, or unenforceable, then that term or provision shall be treated as changed or reduced, only to the extent minimally necessary to bring it within the laws of that jurisdiction and to prevent it from being void, it shall be binding in that changed or reduced form. Subject to this Clause, each provision and term shall be interpreted as severable and shall not in any way affect any other term and condition. The remaining Terms and Conditions will remain in full force and effect.
In the event of any conflict between any provision of these Terms and Conditions and the provisions of the constitution of a limited company or any comparable document intended to regulate any other corporate or collective body, then the provisions of these Terms and Conditions shall prevail.
Our failure to enforce any provision of these Terms and Conditions will not be deemed a waiver of such provision, nor of the right to enforce such provision at a later time.
The validity, construction, and performance of these Terms and Conditions will be governed by and construed in accordance with the laws of the Republic of Panama applicable therein, excluding its conflicts of law rules and principles.
Subject to Clause 15, any legal action or proceedings arising under these Terms and Conditions will be brought exclusively in the courts located in the Republic of Panama and the parties irrevocably consent to the personal jurisdiction and venue there.
We will not be liable for any failure or delayed performance of our obligations that result from any condition beyond our reasonable control, including, but not limited to, governmental action, acts of terrorism, earthquake, fire, flood, acts of God, labour conditions, power failures, Internet disturbances, or acts or omissions of third parties.
You acknowledge, covenant, and agree that we may provide you with notices (including, without limitation those regarding changes to these Terms and Conditions) by email, or postings on the App, our Website, or our social media platforms. By providing us with your email address, you consent to our using the email address to send you any notices required by law in lieu of communication by postal mail.
