Manager Contracts
The Manager Contracts are the main entry points to the Frictionless protocol, they perform market functions such as permission management, treasury operations, issuance, transfer and settlement of securities, and attestations of deposits (proof-of-reserve) for the underlying of FrictionlessFundDepositTokens.
There are four main manager contracts in the Frictionless protocol, as described below.
The FrictionlessPermissionsManager defines a set of functions and events related to managing participants' permissions in the Frictionless protocol.
The interface includes an enumeration FrictionlessPermissionedUser that enumerates different participants in the Frictionless protocol, such as PROTOCOL_TREASURY, PERMISSIONED_CUSTODIAN, etc.
Only valid agents can register, add or remove users and their associated claims.
The FrictionlessTransferManager manages the transfer of tokens within the Frictionless protocol. It is also responsible for the collection of fees associated with the exchange of tokens. These fees are mapped to specific fee schedules set by managers on their respective issuances.
The FrictionlessTransferManager overview is provided in the source README.
The Frictionless protocol enables GPs and Managers to collect fees on the primary issuance and secondary trades of digital securities.
The Frictionless protocol enables Investors to bilaterally trade digital securities via the FrictionlessTransferManager smart contract whilst enabling Managers to optionally collect fees on the transaction.
SeeonlyCounterpart mode
The Frictionless protocol enables Managers and GPs to control cash distributions, waterfalls, and capital calls without the direct action of Investors, enabling sophisticated automation via the Frictionless Markets APIs and Manager automation interface.
See onlyTreasury mode
onlyTreasury Mode
exchangeTokens , this function will execute the exchange of tokens between two counterparties, but it is executed by the PROTOCOL_TREASURY as the transfer agent optionally collecting fees. For example, payment in FrictionlessFundDepositToken by an Investor for FricitonlessDigitalSecurityToken held by a custodian (Primary trade) or FricitonlessDigitalSecurityToken held by another Investor (secondary trade).
The exchange flow is as follows:
The PROTOCOL_ADMIN optionally sets the transfer fees for the token inbound and outbound.
The PROTOCOL_TREASURY invokes the
exchangeTokensfunction, indicating the polarity of the transaction, such as cash for cash, cash for security, security for cash, or security for security. There are many options, but they all result in the same outcome, the compliant transfer of a Frictionless token for another Frictionless token in a single atomic transaction on-chain.The transfer is enacted using the ERC-3643-compliant token transfer
IToken.forcedTransfer.
More scenarios for DvP are described in the source README.
onlyCounterpart Mode
createTransferOffer confirmTransferOffer, cancelTransferOffer these functions will execute the exchange tokens in a bilateral P2P mode between two counterparties in a maker-taker mode. This mode also optionally enables the protocol to collect fees.
The exchange flow is as follows:
The PROTOCOL_ADMIN optionally sets the transfer fees for the token inbound and outbound.
Investor X invokes the
createTransferOfferfunction, indicating the offer, such as cash for cash, cash for security, security for cash, or security for security. There are many options, but they all result in the same outcome, the compliant transfer of a Frictionless token for another Frictionless token in a single atomic transaction on-chain.Investor Y can accept the offer by invoking the
confirmTransferOfferfunction, ensuring the ERC-3643-compliant token transfer usingIToken.transferFrom.
The FrictionlessTreasuryManager manages the minting, transfer, and burning of various tokens within the Frictionless protocol
Token Minting and Management:
The contract provides functions to mint different types of tokens within the Frictionless protocol, including Fund Deposit Tokens (
mintFundDepositForTreasury), Digital Security Tokens (mintDigitalSecurity), and On-Chain Asset Tokens (mintOnChainAsset).Tokens are associated with compliance contracts, and their minting is subject to specific conditions, roles, and permissions.
Token Transfer and Burning:
The contract allows for the transfer and burning of tokens through functions like
transferTokenandburnToken. These actions are performed by an agent with the necessary permissions.
Fund Deposit Token Management:
The contract keeps track of existing Fund Deposit Tokens using a mapping
_existingFundDepositTokens. It prevents the creation of duplicate Fund Deposit Tokens for the same currency and fund IBAN.
The PROTOCOL_ADMIN is the only role permissioned to initially mint any Frictionless tokens, thereafter valid agents such as the PROTOCOL_TREASURY are permitted to increase supply (mint to address), transfer and burn Frictionless tokens.
The FrictionlessAttestationManager responsible for providing attestations of the balances held in the underlying funding account for each FrictionlessFundDepositToken. The attestation is provided and signed by an independent 3rd party, known as PERMISSIONED_FUND_ACCOUNTANT in the Frictionless protocol.
Attestations are proof of balances in each currency on a regular basis for example, daily or hourly, the attestation data is based on the following snapshot of the currency account underpinning the FrictionlessFundDepositToken.
| ATTESTATION FIELD | ATTESTATION COMMENT |
|---|---|
CASH_IBAN | The IBAN of the cash account |
CURRENCY | The 3-letter currency code of the cash account |
REPORT_START_DATE | The start of this report, for example, yesterday at 6AM |
REPORT_END_DATE | The end of this report, for example, today at 6AM |
CASH_BALANCE | The actual balance on the account as of |
LAST_TX_COUNTERPARTY_ID | The ID of the counterparty in the last transaction on the account |
LAST_TX_TIMESTAMP | The timestamp (same format as REPORT_END_DATE) in the last transaction on the account |
LAST_TX_AMOUNT | The amount of the the last transaction on the account, A credit transaction is positive and a debit transaction is negative |
The attestation workflows are described in the source README.
Last updated
