# Overview Amp is a universal collateral token designed to facilitate fast and efficient transfers for any real-world application. When using Amp as collateral, transfers of value are guaranteed and can settle instantly. While the underlying asset reaches final settlement, a process that can take anywhere from seconds to days, Amp is held in escrow by a collateral manager. Once the transaction successfully settles, the Amp collateral is released and made available to collateralize another transfer. Amp exists to serve as universal collateral for anyone and any project. #### Digital collateral When transferring digital assets, there is a natural push and pull between speed and security. With digital asset transfers, the more confirmations the recipient waits for, the more permanent the transaction becomes. However, waiting for several confirmations may not be practical in many real-life situations, such as payments, when speed is of the essence. This inherent tradeoff between speed and security has made it challenging to use cryptocurrencies in the real world. By serving as collateral for asset transfers, Amp provides speed without compromising on security. In essence, Amp becomes a universal clearing layer for transfers and unlocks assets that would otherwise require waiting for confirmations before being put to use. #### What makes Amp unique Collateral managers (similar to escrow accounts) can be customized with different rules and specifications to fit a variety of use cases. Anyone can create a collateral manager using Amp as collateral, making it useful for applications that benefit from efficient value transfers or escrow services. Amp also includes token partitions, which function like traditional hard disk partitions, allowing different regions to be managed independently. These partitions within the Amp token contract enable different collateral managers to enforce rules on separate, distinct spaces linked to the same digital address. This allows users to “stake” tokens without needing to transfer them to a smart contract. #### Real-world use cases Collateral for payment networks: Projects like [Flexa](https://flexa.co/) use Amp to enable instant, fraud-free payments to merchants across its network. Apps that integrate Flexa pool Amp to ensure all payments can be settled in real-time regardless of the asset or protocol used. Collateral for individuals: Users can often collateralize their own asset transfers, for instance, to gain immediate margin relief on an exchange. In this situation a user can assign Amp to a collateral manager and transfer another asset without requiring excessive transaction fees. The exchange counterparty can allow the underlying asset to be used immediately since Amp is effectively escrowed against the value of the transaction. Collateral for DeFi platforms: New DeFi platforms and protocols are constantly evolving global finance and many are adding Amp to their products. This has further diversified the current and future uses for Amp, and effectively increases its collateral quality. # API reference | Function | | ----------------------------------------------------------------------------------------------------------- | | [`constructor(swapTokenAddress, name, symbol)`](#constructor) | | [`totalSupply()`](#totalsupply) | | [`balanceOf(tokenHolder)`](#balanceof) | | [`transfer(to, value)`](#transfer) | | [`transferFrom(from, to, value)` ](#transferfrom) | | [`allowance(owner, spender)`](#allowance) | | [`approve(spender, value)`](#approve) | | [`increaseAllowance(spender, addedValue)`](#increaseallowance) | | [`decreaseAllowance(spender, substractedValue)`](#decreaseallowance) | | [`swap(from)`](#swap) | | [`balanceOfByPartition(partition, tokenHolder)`](#balanceofbypartition) | | [`partitionsOf(tokenHolder)`](#partitionsof) | | [`transferByPartition(partition, from, to, value, data, operatorData)`](#transferbypartition) | | [`authorizeOperator(operator)`](#authorizeoperator) | | [`revokeOperator(operator)`](#revokeoperator) | | [`authorizeOperatorByPartition(partition, operator)`](#authorizeoperatorbypartition) | | [`revokeOperatorByPartition(partition, operator)`](#revokeoperatorbypartition) | | [`isOperator(operator, tokenHolder)`](#isoperator) | | [`isOperatorForPartition(partition, operator, tokenHolder)` ](#isoperatorforpartition) | | [`isOperatorForCollateralManager(partition, operator, collateralManager)`](#isoperatorforcollateralmanager) | | [`name()`](#name) | | [`symbol()`](#symbol) | | [`decimals()`](#decimals) | | [`granularity()`](#granularity) | | [`totalPartitions()`](#totalpartitions) | | [`allowanceByPartition(partition, owner, spender)`](#allowancebypartition) | | [`approveByPartition(partition, spender, value)` ](#approvebypartition) | | [`increaseAllowanceByPartition(partition, spender, addedValue)`](#increaseallowancebypartition) | | [`decreaseAllowanceByPartition(partition, spender, subtractedValue)`](#decreaseallowancebypartition) | | [`registerCollateralManager(collateralManager)`](#registercollateralmanager) | | [`isCollateralManager(collateralManager)`](#iscollateralmanager) | | [`setPartitionStrategy(prefix, implementation)`](#setpartitionstrategy) | | [`isPartitionStrategy(prefix)`](#ispartitionstrategy) | | [`owner()`](#owner) | | [`authorizedNewOwner()`](#authorizednewowner) | | [`authorizeOwnershipTransfer(_authorizedAddress)`](#authorizeownershiptransfer) | | [`assumeOwnership()`](#assumeownership) | | [`canImplementInterfaceForAddress(_interfaceHash,undefined)`](#canimplementinterfaceforaddress) | ## Function #### `constructor` `constructor(swapTokenAddress, name, symbol)` Initialize AMP, initialize the default partition, and register the contract implementation in the global ERC1820Registry. | Parameter Name | Status | Type | Description | | ------------------ | -------- | ------- | ------------------------------------------------------------------- | | `swapTokenAddress` | Required | address | The address of the ERC-20 token that is set to be swappable for AMP | | `name` | Required | string | Name of the token to be initialized | | `symbol` | Required | string | Symbol of the token to be initialized | #### `totalSupply` `totalSupply()` Retrieves the total number of minted tokens. **Returns** `Amp.totalSupply` returns a `uint256` containing the total number of minted tokens. #### `balanceOf` `balanceOf(tokenHolder)` Retrieves the balance of the account with address `tokenHolder` across all partitions. Note that this figure should not be used as the arbiter of the amount a token holder will successfully be able to send via the ERC-20 compatible `Amp.transfer` method. In order to get that figure, use `Amp.balanceOfByPartition` to get the balance of the default partition. **Method parameters**
Parameter NameStatusTypeDescription
Parameter NameStatusTypeDescription
tokenHolderRequiredaddressAddress for which the balance is returned.
**Returns** `Amp.balanceOf` returns a `uint256` containing the amount of tokens held by `tokenHolder` across all partitions. #### `transfer` `transfer(to, value)` Transfers an amount of tokens to the specified address. Note that this only transfers from the `msg.sender` address's default partition. To transfer from other partitions, use function `Amp.transferByPartition`. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ------------------------------------------------------ | | `to` | Required | address | The address to which the tokens should be transferred. | | `value` | Required | uint256 | The amount of tokens to be transferred. | **Returns** `Amp.transfer` returns a `bool` indicating whether the operation was successful. #### `transferFrom` `transferFrom(from, to, value)` Transfers an amount of tokens between two accounts. Note that this only transfers from the `from` address's default partition. To transfer from other partitions, use function `Amp.transferByPartition`. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | -------------------------------------------------------- | | `from` | Required | address | The address from which the tokens are to be transferred. | | `to` | Required | address | The address to which the tokens should be transferred. | | `value` | Required | uint256 | The amount of tokens to be transferred. | **Returns** `Amp.transferFrom` returns a `bool` indicating whether the operation was successful. #### `allowance` `allowance(owner, spender)` Retrieves the allowance of tokens that has been granted by `owner` to `spender` for the default partition. Note that this only returns the allowance of the `owner` address's default partition. To retrieve the allowance for a different partition, use function `Amp.allowanceByParititon`. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ----------------------------------------------------------- | | `owner` | Required | address | The address holding the authorized tokens. | | `spender` | Required | address | The address authorized to transfer the tokens from `owner`. | **Returns** `Amp.allowance` returns a `uint256` specifying the amount of tokens available for the `spender` to transfer from the `owner`'s default partition. #### `approve` `approve(spender, value)` Sets an allowance for an address to transfer an amount of tokens on behalf of the caller. Note that this only affects the `msg.sender` address's default partition. To approve transfers from other partitions, use function `Amp.approveByPartition`. This method is required for ERC-20 compatibility, but is subject to the race condition described in . Functions `Amp.increaseAllowance` and `Amp.decreaseAllowance` should be used instead. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ------------------------------------------------------------------------------------------ | | `value` | Required | uint256 | The amount of tokens to be authorized. | | `spender` | Required | address | The address which is authorized to transfer tokens from default partition of `msg.sender`. | **Returns** `Amp.approve` returns a `bool` indicating if the operation was successful. #### `increaseAllowance` `increaseAllowance(spender, addedValue)` Increases the allowance granted to `spender` by the caller. This is an alternative to `Amp.approve` that can be used as a mitigation for the race condition described in . Note that this only affects the `msg.sender` address's default partition. To increase the allowance for other partitions, use function `Amp.increaseAllowanceByPartition`. **Requirements:** * `spender` cannot be the zero address. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | -------------------------------------------------------------------------------- | | `spender` | Required | address | The account authorized to transfer the tokens. | | `addedValue` | Required | uint256 | Additional amount of the `msg.sender`'s tokens `spender` is allowed to transfer. | **Returns** `Amp.increaseAllowance` returns a `bool` indicating if the operation was successful. #### `decreaseAllowance` `decreaseAllowance(spender, substractedValue)` Decreases the allowance granted to `spender` by the caller. This is an alternative to `Amp.approve` that can be used as a mitigation for the race condition described in . Note that this only affects the `msg.sender` address's default partition. To decrease the allowance for other partitions, use function `decreaseAllowanceByPartition`. **Requirements:** * `spender` cannot be the zero address. * `spender` must have an allowance for the caller of at least `subtractedValue`. **Method parameters** | Parameter Name | Status | Type | Description | | ------------------ | -------- | ------- | --------------------------------------------------------------------------------------------------------------------- | | `spender` | Required | address | Account whose authorization to transfer tokens is to be decreased. | | `substractedValue` | Required | uint256 | Amount by which the authorization for `spender` to transfer tokens held by `msg.sender`'s account is to be decreased. | **Returns** `Amp.decreaseAllowance` returns a `bool` indicating if the operation was successful. #### `swap` `swap(from)` Exchanges an amount of source swap tokens from the contract defined at deployment for the equivalent amount of Amp tokens. Requires the `from` account to have granted the Amp contract an allowance of swap tokens no greater than their balance. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ---------------------------------------------------------------- | | `from` | Required | address | Token holder whose swap tokens will be exchanged for AMP tokens. | #### `balanceOfByPartition` `balanceOfByPartition(partition, tokenHolder)` Retrieves the balance of a token holder for a specific partition. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ------------------------------------------------ | | `partition` | Required | bytes32 | The partition for which the balance is returned. | | `tokenHolder` | Required | address | Address for which the balance is returned. | **Returns** `Amp.balanceOfByPartition` returns a `uint256` containing the amount of tokens held by `tokenHolder` in `partition`. #### `partitionsOf` `partitionsOf(tokenHolder)` Retrieves the set of partitions for a particular token holder. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ---------------------------------------------- | | `tokenHolder` | Required | address | Address for which the partitions are returned. | **Returns** `Amp.partitionsOf` returns a `bytes32[]` containing the partitions of `tokenHolder`. #### `transferByPartition` `transferByPartition(partition, from, to, value, data, operatorData)` Transfers tokens from a specific partition on behalf of a token holder, optionally changing the partition and including arbitrary data used by the partition strategies and collateral managers to authorize the transfer. This can be used to transfer an address's own tokens, or transfer a different address's tokens by specifying the `from` param. If attempting to transfer from a different address than `msg.sender`, the `msg.sender` will need to be an operator or have enough allowance for the `partition` of the `from` address. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ------------------------------------------------------------------------------------------------------------------------- | | `partition` | Required | bytes32 | The partition from which the tokens are to be transferred. | | `from` | Required | address | Address from which the tokens are to be transferred. | | `to` | Required | address | Address to which the tokens are to be transferred. | | `value` | Required | uint256 | Amount of tokens to be transferred. | | `data` | Required | bytes | Information attached to the transfer. Will contain the destination partition if changing partitions. | | `operatorData` | Required | bytes | Additional data attached to the transfer. Used by partition strategies and collateral managers to authorize the transfer. | **Returns** `Amp.transferByPartition` returns a `bytes32` containing the destination partition. #### `authorizeOperator` `authorizeOperator(operator)` Authorizes an address as an operator of `msg.sender` to transfer tokens on its behalf. Note that this applies to all partitions. `msg.sender` is always an operator for itself, and does not need to be explicitly added. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ----------------------------------------------- | | `operator` | Required | address | Address to set as an operator for `msg.sender`. | #### `revokeOperator` `revokeOperator(operator)` Remove the right of the `operator` address to be an operator for `msg.sender` and to transfer tokens on its behalf. Note that this affects the account-wide authorization granted via function `Amp.authorizeOperator`, and does not affect authorizations granted via function `Amp.authorizeOperatorByPartition`. `msg.sender` is always an operator for itself, and cannot be removed. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | -------------------------------------------------------- | | `operator` | Required | address | Address to be deauthorized an operator for `msg.sender`. | #### `authorizeOperatorByPartition` `authorizeOperatorByPartition(partition, operator)` Authorizes an account as an operator of a particular partition. The `msg.sender` is always an operator for itself, and does not need to be explicitly added to a partition. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ----------------------------------------------------------- | | `partition` | Required | bytes32 | The partition for which the `operator` is to be authorized. | | `operator` | Required | address | Address to be authorized as an operator for `msg.sender`. | #### `revokeOperatorByPartition` `revokeOperatorByPartition(partition, operator)` Deauthorizes an address as an operator for a particular partition. Note that this does not override an account-wide authorization granted via function `Amp.authorizeOperator`. `msg.sender` is always an operator for itself, and cannot be removed from a partition. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ------------------------------------------------------- | | `partition` | Required | bytes32 | The partition for which the `operator` is deauthorized. | | `operator` | Required | address | Address to deauthorize as an operator for `msg.sender`. | #### `isOperator` `isOperator(operator, tokenHolder)` Indicates whether the `operator` address is an operator of the `tokenHolder` address. Note that this applies to all of the partitions of the `msg.sender` address. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ------------------------------------------------------------------------------- | | `operator` | Required | address | Address which may be an operator of `tokenHolder`. | | `tokenHolder` | Required | address | Address of a token holder which may have the `operator` address as an operator. | **Returns** `Amp.isOperator` returns a `bool` indicating whether `operator` is an operator of `tokenHolder`. #### `isOperatorForPartition` `isOperatorForPartition(partition, operator, tokenHolder)` Indicate whether the `operator` address is an operator of the `tokenHolder` address for the `partition` **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | --------------------------------------------------------------------------------------------------- | | `partition` | Required | bytes32 | Partition for which `operator` may be authorized. | | `operator` | Required | address | Address which may be an operator of `tokenHolder` for the `partition`. | | `tokenHolder` | Required | address | Address of a token holder which may have the `operator` address as an operator for the `partition`. | **Returns** `Amp.isOperatorForPartition` returns a `bool` indicating whether `operator` is an operator of `tokenHolder` for the `partition`. #### `isOperatorForCollateralManager` `isOperatorForCollateralManager(partition, operator, collateralManager)` Indicates whether the `operator` address is an operator of the `collateralManager` address for the `partition`. This method is functionally identical to `Amp.isOperatorForPartition`, except that it also requires the address that `operator` is being checked for must be a registered collateral manager. **Method parameters** | Parameter Name | Status | Type | Description | | ------------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------- | | `partition` | Required | bytes32 | Partition for which `operator` may be authorized. | | `operator` | Required | address | Address which may be an operator of `collateralManager` for the `partition` | | `collateralManager` | Required | address | Address of a collateral manager which may have the `operator` address as an operator for the `partition`. | **Returns** `Amp.isOperatorForCollateralManager` returns a `bool` indicating whether the `operator` address is an operator of the `collateralManager` address for the `partition`. #### `name` `name()` Retrieves the name of the token. **Returns** `Amp.name` returns a `string` containing the name of the token. Always "Amp". #### `symbol` `symbol()` Retrieves the symbol of the token. **Returns** `Amp.symbol` returns a `string` containing the symbol of the token. Always "AMP". #### `decimals` `decimals()` Retrieves the number of decimals of the token. **Returns** `Amp.decimals` returns a `uint8` containing the number of decimals of the token. Always 18. #### `granularity` `granularity()` Retrieves the smallest part of the token that is not divisible. **Returns** `Amp.granularity` returns a `uint256` containing the smallest non-divisible part of the token. Always 1. #### `totalPartitions` `totalPartitions()` Retrieves the set of existing partitions. **Returns** `Amp.totalPartitions` returns a `bytes32[]` containing all partitions. #### **`allowanceByPartition`** `allowanceByPartition(partition, owner, spender)` Retrieves the allowance of tokens that has been granted by a token holder to another account. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ------------------------------------------------------------------------------ | | `partition` | Required | bytes32 | Partition for which the spender may be authorized. | | `owner` | Required | address | The address which owns the tokens. | | `spender` | Required | address | The address which is authorized transfer tokens on behalf of the token holder. | **Returns** `Amp.allowanceByPartition` returns a `uint256` containing the amount of tokens available for `spender` to transfer. #### `approveByPartition` `approveByPartition(partition, spender, value)` Approves the `spender` address to transfer the specified amount of tokens in `partition` on behalf of `msg.sender`. Note that this method is subject to the race condition described in . Functions `Amp.increaseAllowanceByPartition` and `Amp.decreaseAllowanceByPartition` should be used instead. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | ------------------------------------------------------------------------- | | `partition` | Required | bytes32 | Partition for which the `spender` is to be authorized to transfer tokens. | | `spender` | Required | address | The address of the account to be authorized to transfer tokens. | | `value` | Required | uint256 | The amount of tokens to be authorized. | **Returns** `Amp.approveByPartition` returns a `bool` indicating if the operation was successful. #### `increaseAllowanceByPartition` `increaseAllowanceByPartition(partition, spender, addedValue)` Increases the allowance granted to an account by the caller for a partition. This is an alternative to function `Amp.approveByPartition` that can be used as a mitigation for the race condition described in **Requirements:** * `spender` cannot be the zero address. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------- | -------------------------------------------------------------------------------- | | `partition` | Required | bytes32 | Partition for which the `spender` is to be authorized to transfer tokens. | | `spender` | Required | address | The address of the account to be authorized to transfer tokens. | | `addedValue` | Required | uint256 | Additional amount of the `msg.sender`'s tokens `spender` is allowed to transfer. | **Returns** `Amp.increaseAllowanceByPartition` returns a `bool` indicating if the operation was successful. #### `decreaseAllowanceByPartition` `decreaseAllowanceByPartition(partition, spender, subtractedValue)` Decreases the allowance granted to `spender` by the caller. This is an alternative to function `Amp.approveByPartition` that can be used as a mitigation for the race condition described in **Requirements:** * `spender` cannot be the zero address. * `spender` must have an allowance for the caller of at least `subtractedValue`. **Method parameters** | Parameter Name | Status | Type | Description | | ----------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------- | | `partition` | Required | bytes32 | Partition for which `spender`'s allowance is to be decreased. | | `spender` | Required | address | Amount by which the authorization for `spender` to transfer tokens held by `msg.sender`'s account is to be decreased. | | `subtractedValue` | Required | uint256 | Amount of the `msg.sender`'s tokens `spender` is no longer allowed to transfer. | **Returns** `Amp.decreaseAllowanceByPartition` returns a `bool` indicating if the operation was successful. #### `registerCollateralManager` `registerCollateralManager(collateralManager)` Registers `msg.sender` as a collateral manager. #### `isCollateralManager` `isCollateralManager(collateralManager)` Retrieves whether the supplied address is a collateral manager. **Method parameters** | Parameter Name | Status | Type | Description | | ------------------- | -------- | ------- | -------------------------------------- | | `collateralManager` | Required | address | The address of the collateral manager. | **Returns** `Amp.isCollateralManager` returns a `bool` indicating whether `collateralManager` is registered as a collateral manager. #### `setPartitionStrategy` `setPartitionStrategy(prefix, implementation)` Sets an implementation for a partition strategy identified by `prefix`. Note: this function can only be called by the contract owner. **Method parameters** | Parameter Name | Status | Type | Description | | ---------------- | -------- | ------- | -------------------------------------------------------- | | `prefix` | Required | bytes4 | The 4 byte partition prefix the strategy applies to. | | `implementation` | Required | address | The address of the implementation of the strategy hooks. | #### `isPartitionStrategy` `isPartitionStrategy(prefix)` Return whether the `prefix` has had a partition strategy registered. **Method parameters** | Parameter Name | Status | Type | Description | | -------------- | -------- | ------ | ---------------------------------- | | `prefix` | Required | bytes4 | The partition strategy identifier. | **Returns** `Amp.isPartitionStrategy` returns a `bool` indicating if the strategy has been registered. #### `owner` `owner()` Retrieves the owner of the contract **Returns** `Amp.owner` returns an `address` containing the contract owner. #### `authorizedNewOwner` `authorizedNewOwner()` Retrieves the authorized new owner of the contract **Returns** `Amp.authorizedNewOwner` returns an `address` containing the authorized new contract owner. #### `authorizeOwnershipTransfer` `authorizeOwnershipTransfer(authorizedAddress)` Authorizes the transfer of ownership from owner to the provided address. Note that the transfer will not occur until `authorizedAddress` calls function `Amp.assumeOwnership`. This authorization may be removed by another call to this function authorizing the zero address. **Method parameters** | Parameter Name | Status | Type | Description | | ------------------- | -------- | ------- | ---------------------------------------------- | | `authorizedAddress` | Required | address | The address authorized to become the new owner | #### `assumeOwnership` `assumeOwnership()` Transfers ownership of this contract to the authorized new owner. #### `canImplementInterfaceForAddress` `canImplementInterfaceForAddress(interfaceHash,undefined)` Indicates whether the contract implements the interface `interfaceHash`. **Method parameters** | Parameter Name | Status | Type | Description | | --------------- | -------- | ------- | -------------------------------------------- | | `interfaceHash` | Required | bytes32 | keccak256 hash of the name of the interface. | | `undefined` | Required | address | | **Returns** `Amp.canImplementInterfaceForAddress` returns a `bytes32` containing the ERC-1820 "accept magic" string if the contract implements `ìnterfaceHash`. # Contracts and audits ### **AMP token contract** > [0xff20817765cb7f73d4bde2e66e067e58d11095c2](https://etherscan.io/address/0xff20817765cb7f73d4bde2e66e067e58d11095c2) {% hint style="info" %} **Do not send digital assets to the AMP contract for any reason; tokens will be *****permanently unrecoverable*****.** {% endhint %} ### Security Audits The AMP token contract and related source materials have been audited by independent security researchers at ConsenSys Diligence and Trail of Bits**.** In June 2020, ConsenSys Diligence audited the AMP smart contracts. ConsenSys found zero critical issues and shared fifteen recommendations related to developer experience and other optimizations, which have been implemented. In July and August 2020, Trail of Bits audited the AMP smart contracts and related collateral management contracts. Trail of Bits also found zero critical issues and shared one low-severity recommendation, which has since been acknowledged. **Consensys Diligence Audit:** > **Trail of Bits Audit:** > # Whitepaper The AMP whitepaper introduces the primary technical elements of the AMP token contract and collateral managers. In particular, it presents novel partition strategies for enabling "stake-in-place" designs for Ethereum tokens. The paper also presents an analysis of legacy payment infrastructure, distributed payment networks, and token economics. This research uses established economic models in addition to a unique, in-depth assessment of the long-term utility, value, and stability of a collateral token network. Sections include: * **Digital Payments and the Flexa Network** * **Decentralized collateral** * Finality assurance and scale * Meta-staking and risk distribution * **Amp token contract** * Operators and partition scopes * Partition strategies * Token hooks * Flexa collateral manager * Further extensibility * **Token economics** * Production model * Tokenization model * Network efficiency model * Stability analysis {% file src="/files/FT3GMsOtddJAr84hIPVq" %} # Community and resources Join the Amp community to connect with other developers and network participants, receive project updates, and help guide the future of the platform. * [Discord](https://discord.com/invite/6GWGjzPsc4) * [Facebook](https://www.facebook.com/groups/1286502338388975) * [Reddit](https://www.reddit.com/r/AMPToken/) * [Substack newsletter](https://amptoken.substack.com)\* * [Telegram](https://t.me/ampchat) * [X](https://x.com/ampdotxyz)\* Additional resources * [Dune dashboard](https://dune.com/ampdotxyz/amp-token) * [Flexa Capacity](https://app.flexa.co/) * [Github](https://github.com/amptoken)\* * [SPEDN app](https://spedn.io/) * [Youtube (AF)](https://www.youtube.com/@AcronymFoundation)\* \*Supported by the Acronym Foundation # Brand assets For media or commercial use. {% file src="/files/R4DzmLn9eCHcOYtjVJyA" %} {% file src="/files/KedAyYi2Udk7HXG8Vofn" %} {% file src="/files/6qdM9CJBjNuayggi7r2w" %} {% file src="/files/dCBgqSrUqJFQo0ZrGl2w" %} # Grants # Overview The Amp Grant Program backs builders pushing the digital payments ecosystem forward, offering funding and support for the projects turning real-world utility into everyday reality. The program focuses on these primary categories: * Open source tooling * Payment integrations * Research * Community building * Educational content * Events Our goal is to grow the ecosystem through education and community development, emphasizing community participation and engagement. The program encourages contributions and incentivizes active participation to enhance understanding and foster the creation of payment-related projects. *** ### Grant types The Program offers three types of grants to support a diverse range of projects, each with specific review processes and response times. **Small grants:** * Funding: Under $10,000 * Review: Grant committee * Response Time: 1 week **Medium grants:** * Funding: $10,000 - $50,000 * Review: Grant committee * Response Time: 2 weeks **Large grants:** * Funding: $50,000+ * Review: Grant committee and Acronym Foundation * Response Time: up to 4 weeks *** ### Grant process The Program follows a structured process to ensure fair and thorough evaluation of all applications. The process includes the following steps: 1. Submit application * [Apply here](https://forms.gle/8sCqseaBRMwN9pik8) 2. Evaluation * Amp Grant Committee (AGC) evaluation * Acronym Foundation (AF) evaluation (for large grants) * Applicant interview (video call) for all grants 3. Sign grant agreement 4. Funds distribution *** ### Grant disbursement The Program ensures that funds are disbursed in a manner that supports the successful completion of projects. The disbursement process varies based on the size and nature of the grant: * Small grants: Funds distributed after approval * Medium grants: * 50% disbursed on MVP completion * 50% disbursed on project completion * Large grants: Milestone-based disbursement *** # Committee review The Amp Grant Committee plays a vital role in reviewing and approving grant applications. This committee consists of members designated from the community-at-large and the Acronym Foundation (AF). * The committee consists of eight (8) community members and one (1) member from the Acronym Foundation * All committee members serve on a volunteer basis * Each committee member serves a term of 12 months * Community members can submit applications to join the committee * The current grant committee reviews new applications and selects the best candidates for the subsequent term *** # Request for Proposal The Amp Grant Program periodically issues Requests for Proposals (RFP) to direct builders towards high-impact areas within the digital payments ecosystem. These RFPs are open to anyone, including established teams and previous grant recipients. 1. Application process * Builders apply for grants using the same process and form as standard applications * Applicants must indicate on the form if they are responding to an RFP 2. Publication of RFPs * Requests will be posted on the grants section of the Amp GitBook * Each RFP will outline specific milestones and success metrics 3. Application timeline * RFP applications are open for 30 days * If no suitable proposals are received within this period, the application window may be extended as necessary 4. Evaluation and funding * Submissions will be reviewed, and a project winner will be funded based on its potential impact and alignment with the RFP goals *** # Flexa SDK: Wallet Integration ## Overview The Amp Grant Program is issuing an open Request for Proposal (RFP) to mobile wallet application teams interested in enabling Flexa Components in their applications using the Flexa SDK. The goal is to support efforts to build production-grade crypto wallets that allow users to spend their assets directly at thousands of retail locations through Flexa’s merchant network. Flexa Components offers a modern, modular set of user-friendly interfaces that help wallets to enable both in-store and online payments with crypto. Payments are made natively, instantly, and without requiring prepaid cards or third-party rails. This RFP is designed to help teams navigate the integration process, access grant funding, and go live as a Flexa-enabled wallet. ## What is Flexa Components? [Flexa Components](https://flexa.co/components) is Flexa’s next-generation suite of wallet-focused user experiences, and can be integrated using the open-source Flexa SDK (available for iOS, Android, React Native, and Flutter). Components offers: * The Scan component – offers a versatile scanner interface for the fastest parsing of native payment requests, Flexa Payment Links, and WalletConnect QR codes * The Spend component – offers a private and secure barcode-based interface for in-person payments leveraging direct integrations with merchant payment terminals ## RFP Goals We’re looking to fund wallet projects that: * Integrate Flexa’s Scan and Spend components into a self-custodial or managed-custody wallet application * Offer Flexa payment functionality to users at the point-of-sale (POS) or e-commerce checkout * Enable real-world payments across Flexa’s live merchant integrations (Chipotle, GameStop, etc.) ## Ideal outcomes: * Live, production release of Flexa-enabled payments inside a wallet app * Straightforward access to the Flexa Components UI for users (e.g., through a button on the application’s primary view) * Ongoing wallet maintenance and support of Flexa payments functionality ## Who should apply? * Existing crypto wallet projects looking to add retail payment functionality * New teams building wallets for mobile or desktop platforms * Previous grant recipients or Amp community participants * Teams with a focus on payments, meaningful user bases, transaction volume, or product traction are prioritized ## Funding Selected projects may receive up to $20,000, disbursed in two stages: * 50% disbursed on MVP completion * 50% disbursed on project completion ## Integration Resources * Flexa Documentation: [docs.flexa.co](https://docs.flexa.co/introduction) * iOS SDK: [flexa-ios](https://github.com/flexa/flexa-ios) * Android SDK: [flexa-android](https://github.com/flexa/flexa-android) * React Native SDK: [flexa-react-native](https://github.com/flexa/flexa-react-native) ## Application Process * Submit your proposal via the [Amp Grant Application Form](https://docs.google.com/forms/d/e/1FAIpQLSeViZpX_bTNNyMnbSXeF76b55MoRnAKNBrhdbPJuqXNzMw0Eg/viewform?pli=1) * Indicate that you are applying in response to this Wallet Integration RFP * Applications will be reviewed on a rolling basis for 30 days ## Evaluation Criteria * Quality and completeness of the proposed integration plan * Technical ability of the team to execute integration * Size and activity of the wallet’s existing or planned user base * Alignment with mission of advancing real-world crypto payments ## Contact For questions, support, or to discuss your proposal before applying, reach out to: # Support ### Customer support for applicants The Amp Grant Program offers support to applicants to help them through the application process and provide feedback. While support is available, it is not guaranteed. #### Availability of support * Support is offered by the Acronym Foundation (AF) to assist applicants * Applicants can reach out via [email](mailto:support@amp.xyz) for assistance * In some cases, a video call may be arranged to provide further guidance #### Scope of support * Guidance on submitting applications * Feedback on project proposals * Support is provided to projects that align with our focus areas #### Limitations of support * No financial or legal advice * No advice on token-related matters * No assistance with transactions, wallets, or exchanges *** # Tips for submitting an application To improve the chances of your application being successful, consider the following tips: * Clearly articulate the goals and objectives of your project * Explain the broader impact and potential of your project * Provide any relevant documents that can help substantiate your application * Clearly define the problem your project aims to address * Describe why solving this problem is important and how it benefits the greater digital payments ecosystem * Outline the expected results of your project * Specify measurable and tangible outcomes you aim to achieve * Set achievable goals and timelines * Ensure that your funding request aligns with the scope and scale of your project *** #### Required details In addition to the general guidance above, all applicants should include the following materials to help the committee accurately assess your proposal: * A clear explanation of how grant funds will be allocated, including specific categories (e.g., development, marketing, operations) and estimated costs * A schedule outlining key milestones and deadlines for project deliverables, including start and completion dates for each phase If your project involves content creation, public outreach, or education, consider including: * A list of platforms (e.g., X, YouTube, TikTok) you’ll use to promote the project, along with how each will be used *** # FAQs * **Is my application confidential?** * Mostly yes. Your application will be reviewed by the Amp Grant Committee and may be reviewed by the Acronym Foundation. * **Can I remain anonymous?** * Depending on the project’s scope and specifics, confirmation with the core team may be required. * **What asset is the grant given in?** * Grants are disbursed in AMP. * **What happens if I am not approved for a grant?** * Don’t get discouraged, you can apply for another grant. The scope of the grants is wide, providing many opportunities for different projects. ***