AMP token contract

0xff20817765cb7f73d4bde2e66e067e58d11095c2

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:

• 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.

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

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 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

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 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.

For media or commercial use.

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

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

• Token economics

  • Production model

  • Tokenization model

  • Network efficiency model

Join the Amp community to connect with other developers and network participants, receive project updates, and help guide the future of the platform.

• Discord

• Facebook

• Reddit

• *

• *

Additional resources

• *

*Supported by the Acronym Foundation

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

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

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?

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:

• iOS SDK:

• Android SDK:

• React Native SDK:

Application Process

• Submit your proposal via the

• 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:

Function

constructor

constructor(swapTokenAddress, name, symbol)

Initialize AMP, initialize the default partition, and register the contract implementation in the global ERC1820Registry.

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

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

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

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

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

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

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

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

balanceOfByPartition

balanceOfByPartition(partition, tokenHolder)

Retrieves the balance of a token holder for a specific partition.

Method parameters

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

isPartitionStrategy

isPartitionStrategy(prefix)

Return whether the prefix has had a partition strategy registered.

Method parameters

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

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

Returns

Amp.canImplementInterfaceForAddress returns a bytes32 containing the ERC-1820 "accept magic" string if the contract implements ìnterfaceHash.