This mostly technical article provides a universal framework and a working solution for Ethereum tokens and applications that eliminates the need to pay fees in Ether, a problem that is practically killing the user experience of many blockchain applications.
Imagine spending dollars and then being asked to also hand over some Hryvnias as a transaction fee. That's how Ethereum tokens work so far.
想象一下花钱，然后被要求还交纳一些 格里夫纳 作为交易费。 到目前为止，这就是以太坊令牌的工作方式。
In other words, for example, to transfer any Ethereum token (like Tether, DAI, BAT, DREAM, etc.), the user has to also spend some Ether (internal Ethereum platform currency). This introduces a big inconvenience that prevents the mass adoption of DApps: users have to purchase multiple currencies instead of just one to interact with the blockchain network.
问题 (The Problem)
Tokens, as we imagine them today are just fuel for applications and services on top of blockchain networks. Organizations create their own tokens (using ICOs, IEOs, etc) and run services/applications that utilize them, introducing their own micro-economy (widely known as a token economy). But almost every token turns out to be quite a complex currency itself. By design of how blockchain networks work, in order to do something with your tokens, you also need another currency — often Ether (for Ethereum) to be able to transfer tokens.
正如我们今天想象的那样，令牌只是区块链网络之上的应用程序和服务的燃料。 组织创建自己的令牌(使用ICO，IEO等)，并运行利用它们的服务/应用程序，从而引入自己的微观经济(被广泛称为令牌经济 )。 但事实证明，几乎每个代币本身都是一种非常复杂的货币。 通过设计区块链网络的工作方式，为了对令牌做一些事情，您还需要另一种货币-通常是以太坊(以太坊(Ethereum))，以便能够传输令牌。
To illustrate the problem, let's look into how users come to use different blockchain-powered services and applications like:
Trickle - where you create secure, hourly-based contracts with an untrusted party in any token
Loom - where you use Loom tokens to create sidechains in Loom Network
Cryptokitties.co - where you breed, trade and transfer kitties (ERC721 tokens)
Others (there are a lot!)
All these applications use tokens, as well as they require you to purchase Ether. The complexity of using crypto tokens as we know them today is one of the biggest reasons why 99% of crypto startups fail (or avoid adopting real crypto, for example, by replacing it with virtual coins).
As you may already know, the harder it is to use the application, the fewer users it will get right from the beginning. This is something known as The User Onboarding Funnel, which is still a big pain for blockchain-powered applications and services:
您可能已经知道，使用该应用程序越难，从一开始就可以使用的用户越少。 这就是所谓的“用户入门程序” ，对于区块链驱动的应用程序和服务仍然是一个巨大的痛苦：
To understand why I put 0.001% of users prior to the service use, let's see what exactly purchasing some Ether means:
- Creating a crypto wallet
- Registering on Exchange (and learning all the exchange rules, including country policies!)
- Passing KYC (though it's getting easier, still, many countries have limited access to exchanges)
Purchasing a minimum allowed amount of Ether (usually, it's whopping $50 while you need just nearly $0.05 to perform one or two transactions)
- Withdrawing Ether to your wallet
- Not to mention reading lengthy guides on how to perform all these steps properly
Instead of just:
- Creating a crypto wallet
Of course, it highly depends on how the application or service is made. But, so far, there was no better simplification of the onboarding flow as just cutting crypto tokens from there, or making them fake, "virtual" currency with deposit and withdrawal function. Unfortunately, the latter approach is now the common one across all startups and companies adopting crypto, for many good reasons. Another reason could be a monetization strategy, but this is another big story worth a dedicated article (Interested? Comment out!).
当然，这在很大程度上取决于应用程序或服务的制作方式。 但是，到目前为止，没有什么比简化注册流程更好的了，仅仅是从那里切断加密代币，或者使它们成为具有存款和取款功能的伪造“虚拟”货币。 不幸的是，出于多种原因，后一种方法现在已成为所有采用加密技术的初创公司和公司中的通用方法。 另一个原因可能是货币化策略，但这是另一个值得撰写专门文章的大故事(感兴趣吗？请注释掉！)。
Getting back to the transaction fees problem, we can state the following, which is hard to argue with.
It is natural for the user to purchase only the cryptocurrency they really need (for instance, tokens: Tether, DAI, BAT, DREAM, etc.), and they would normally expect to pay any transaction fees in this cryptocurrency.
So why not just allow them to do so? Because it's quite complex indeed. Let's see why, and how this has just got easier with our open-sourced solution (at least for Ethereum).
那么，为什么不让他们这样做呢？ 因为确实很复杂。 让我们看看为什么，以及通过我们的开源解决方案(至少对于以太坊而言)如何变得更加容易。
现有方法 (Existing Approaches)
From the very beginning of blockchain existence, there were a couple of solutions that could simplify the user onboarding flow to the flow depicted below, avoiding the step of purchasing an intermediate currency like Ether. Still, creating a blockchain wallet is not an easy step, but some users who do understand the value of the application/service go through this step quite well.
The solution which allows to avoid using intermediate currencies (Ether for Ethereum) is called "delegated transactions", or "meta transactions".
In short, delegated transaction, or "meta transaction" in blockchain is the type of transaction which performs an intended action on one account's behalf, while it is conducted (published) by another account (delegate), who actually pays fees for the transaction.
There are multiple approaches around the internet of the generalized concept of delegated transactions I am presenting in this article. But it seems that none of them are still widely adopted, as these approaches are quite complex by its nature, very specific as for the implementation, as well as some of them are quite complex to standardize. To be more constructive, existing approaches can be divided into 3-4 groups: those which use proxy smart contracts, those which embed delegation into a smart contract itself and, theoretically, there is an opportunity for the blockchain-native implementation (say, Ethereum 2.0).
1.使用代理合同的委托交易方法 (1. Delegated transactions approaches which use proxy-contracts)
Proxy contracts, or, in this context, identity contracts are tiny contracts deployed to replace the user account which wants to avoid paying fees. This smart contract is programmed to act as a wallet, as well as a "caller" (sender) of other smart contract's functions. The key is that it is a delegate account that triggers all the actions, while the true "owner" of this smart contract is another user. The user just generates correct signatures in order to control their funds stored on a smart contract address (= in their wallet).
代理合同，或者在这种情况下，身份合同，是为避免用户付费而部署的微型合同，用以替换用户帐户。 该智能合约被编程为充当钱包，以及其他智能合约功能的“呼叫者”(发送者)。 关键是它是触发所有操作的委托帐户，而此智能合约的真正“所有者”是另一个用户。 用户只需要生成正确的签名即可控制存储在智能合约地址(=在他们的钱包中)中的资金。
Pros of this approach:
- It works with any tokens and contracts which are already deployed to the network
Cons of this approach:
- Users don't see tokens in their wallet, because they are physically on an identity smart contract
- As a result, a need to develop custom UIs and custom tools/wallets
- Identity smart contract deployment and assignment initial fees, as opposed to no fees at all
- Requires a comprehensive standard to be widely adopted
There is a token standard that describes this approach — ERC777. In short, any token holder can authorize any other account to freely manage their tokens. I won't call it delegated transactions but nevertheless, I need to mention that, as here we somewhat delegate control over your tokens to other accounts.
有一个描述此方法的令牌标准-ERC777 。 简而言之，任何令牌持有者都可以授权任何其他帐户自由管理其令牌。 我不会称其为委托交易，不过，我需要提及的是，在这里，我们在某种程度上将对令牌的控制权委托给了其他帐户。
Pros of this approach:
Cons of this approach:
- Highly centralized around the "operator" accounts
- Weak security due to operators have 100% control over your tokens
- Initial fees for approval transaction
- Requires additional UIs/tools development
3.直接嵌入(令牌)智能合约中的委托交易 (3. Delegated transactions embedded directly into a (token) smart contract)
Just the same as it is possible to implement custom fees in a proxy smart contract, paying fees in tokens can be implemented directly in a token smart contract. For example, using the approach I described in my previous article, it is possible to implement a function in a smart contract, which will transfer tokens accepting the user's signature, instead of requiring the user to call this function directly. We have implemented this approach in our DREAM Token, which is used on our dreamteam.gg platform.
As you may notice, in contrast to the previous approach there is no identity contract anymore, and there is an optional way to call other smart contracts directly from the token contract.
Pros of this approach:
- Users see their tokens as usual on their wallet's balance
- No initial fees for account initialization
- May not even require a standard (continue reading)
Cons of this approach:
- If you have a (token) smart contract that is already deployed to the network, you cannot apply this approach to it directly. While you can always deploy a new token and, for example, a "migration" utility, which will allow other users to swap tokens (burn the old token and mint a new one)
- Because a standard for this approach is yet not well-defined, implementation can drastically vary
- A need to develop custom UI/tools for delegated transactions (continue reading — solved!)
4.(区块链)平台级别的委托交易 (4. Delegated transactions on the (blockchain) platform level)
This is far the best one of all the described approaches above but also the one which is not implemented anywhere yet (by anywhere I mean the most popular blockchain platforms). There is a hope that its support comes with Ethereum 2.0 release, or at least I've heard from Vitalik that they are in progress with something cool there.
这是上述所有方法中最好的方法之一，也是尚未在任何地方(我指的是最受欢迎的区块链平台) 尚未实现的方法 。 希望它的支持随以太坊2.0版本一起提供，或者至少我从Vitalik那里听说他们正在开发一些很棒的东西。
Theoretically, we can imagine this approach as being able to make an "offline" signature of two transactions at a time: one which does something useful for the signing account which wants to avoid paying fees (for example, transferring tokens) and another one which does something useful for the delegate (for example, paying fee in tokens to the account which executes these two transactions).
But the problem is, regarding Ethereum 2.0, this feature has a chance to land only in 2022 or even later. I also suppose that this feature will still require a dedicated back end (similar to the one which is introduced within this article), as it is hard to imagine how miners will accept fees in tokens. Simply put, if some of them refuse to accept fees in tokens than it makes little sense to do it on a "mining" level at all, not to mention how much would it take to track all token prices and volumes across exchanges, in a decentralized manner.
但是问题在于，就以太坊2.0而言，此功能只有在2022年或更晚才有机会登陆。 我还假设此功能仍将需要专用的后端(类似于本文介绍的后端)，因为很难想象矿工将如何接受代币收费。 简而言之，如果其中一些人拒绝接受代币收费，那么在“挖矿”层面上完全没有意义，更不用说跟踪一次交易所中所有代币价格和交易量需要多少钱。分散的方式。
Pros of this approach:
- No need to change smart contracts that were already deployed
- No initial fees for account initialization
- May not even require a custom UI/tools if standardized
Cons of this approach:
- Most likely, will still require a centralized back end (the "delegate")
- Not yet implemented on a platform level (as of 2019)
解决方案 (The Solution)
From the four approaches above, except for the platform-level approach which is yet to be implemented and standardized in 2022+, the most appealing one is the third approach, where we embed delegated functions directly to the token smart contract. Thus, we save the standard token paradigm allowing wallets to normally work with the smart contract and have no need to wait until delegated transactions will land natively in one of the top blockchain platforms. We will stick to this approach and make it universal just below.
从上面的四种方法中，除了2022年以后仍将要实施和标准化的平台级方法之外，最吸引人的一种是第三种方法 ，我们将委托功能直接嵌入到令牌智能合约中。 因此，我们保存了标准令牌范式，该范式允许钱包正常使用智能合约，而无需等待委托交易将本机降落在顶级区块链平台之一中。 我们将坚持这种方法，并使其在下面通用 。
Delegated transactions support programmed right in the token smart contract is awesome. But how to deal with its cons? In fact, the only problem which is tough to deal with (as you cannot modify existing smart contracts), you will need to deploy a new token smart contract if you have already deployed it without delegated functions (for instance, standard ERC20 or ERC721 tokens). The next step, in this case, would be adding a way to migrate tokens from one smart contract to another. For example, you can decide to implement one more function in the new smart contract that will allow token holders to migrate their assets from the old smart contract.
令牌智能合约中已编程的委托交易支持非常棒。 但是如何应对它的弊端呢？ 实际上，唯一一个很难处理的问题(因为您无法修改现有的智能合约)， 如果您已经部署了没有委托功能的新令牌智能合约 (例如，标准ERC20或ERC721令牌)， 则需要部署该新令牌)。 在这种情况下，下一步将是添加一种将令牌从一个智能合约迁移到另一个智能合约的方法。 例如，您可以决定在新的智能合约中实施另一个功能，该功能将允许令牌持有者从旧的智能合约中迁移其资产。
Token migration function implementation can vary, starting from implementing receiveApproval in the new token, if the previous token supports approveAndCall, or ending with utilizing approve + transferFrom framework if you have just a bare minimal ERC20 (the user approves tokens to the new token contract address and then calls a function in the new contract which burns old tokens and mints new ones — but this requires a standard fee for the user for the approval transaction). Actually, there is more: you can decide not to burn old tokens but to "lock" them on a new token smart contract, minting new tokens — this opens an opportunity to implement two-sided token migration, which is awesome — you won't need to list the "new" token on the exchange, while the users will still be able to send the old token to exchanges without fees in Ether! If you are interested, please fill the issue here if you want to know more details on how to do it, because this approach is worth a whole new article.
令牌迁移功能的实现可以有所不同，在新的令牌实施receiveApproval开始，如果先前的令牌支持approveAndCall，或利用结尾批准 + transferFrom框架，如果你只有一个光秃秃的最小ERC20(用户批准小号令牌以新令牌合同地址，然后在新合同中调用一个函数，该函数将燃烧旧令牌并铸造新令牌-但这需要用户支付批准交易的标准费用)。 实际上，还有更多：您可以决定不刻录旧令牌，而是将它们“锁定”在新令牌智能合约上，铸造新令牌-这为实现双向令牌迁移提供了机会，这真是太棒了- 您会赢的。无需在交易所上列出“新”令牌 ，而用户仍然可以在Ether中免费将旧令牌发送到交易所！ 如果您有兴趣，请在此处填写问题，以了解更多有关操作方法的详细信息，因为这种方法值得一本全新的文章。
In my previous article, I provided an example of the token smart contract which supports delegation of such functions like transfer, transferFrom, approve and approveAndCall. Exactly these "delegated" functions allow users to pay fees in tokens, instead of Ether.
在我的上一篇文章中 ，我提供了令牌智能合约的示例，该合约支持诸如以下功能的委托： transfer ， transferFrom ， approve和approveAndCall 。 正是这些“授权”功能允许用户以代币而不是以太币支付费用。
But that wasn't enough to start the mass adoption. In this article, I am providing a complete universal back end solution (Transaction Publisher in the picture above), as well as a configurable widget (check it here), which allows you to replace Ether fees for token fees today.
Some key points before we dive in:
This delegated transactions back end is made to be universal, or standard-free, meaning that you can have any implementation of delegated functions and use any signature standard(s) in your token. From the back end standpoint, you just need to write a manifest file for your token, describing its usage.
该委派事务后端是通用的或不包含标准的 ，这意味着您可以实现委派函数的任何实现 ，并在令牌中使用任何签名标准 。 从后端的角度来看，您只需要为令牌编写一个清单文件，说明其用法。
- Currently, converting collected fees in tokens back to Ether is a manual action on exchanges. But it could be a potential improvement for automation in the future (if needed).
通用解决方案背后的概念 (The Concept Behind the Universal Solution)
What does it mean that the token supports delegated transactions? Let's look at it using the ERC20 standard token as an example.
智能合约 (Smart Contract)
As for the token smart contract, the approach is quite straightforward. In addition to every method like transfer(to, value) which we want to be "delegatable", we add a companion function which, instead of inspecting msg.sender, accepts the signature of a user and does the same what the original function meant to do by validating this signature inside the smart contract. Thus, for example, for transfer(to, value) function we can add transferViaSignature(to, value, ...aditionalParams) function. As you know from public-key cryptography, no one can create a valid signature except private key owner, so that's why this approach is as secure as Ethereum itself.
对于令牌智能合约，该方法非常简单。 除了我们希望“可委托”的每个方法(例如transfer(to，value))之外 ，我们还添加了一个伴随函数，该函数无需检查msg.sender而是接受用户的签名，并且与原始函数的含义相同通过验证智能合约中的签名来完成。 因此，例如，对于transfer(to，value)函数，我们可以添加transferViaSignature(to，value，... aditionalParams)函数。 从公钥加密中可以知道，除了私钥所有者之外，没有人可以创建有效的签名，因此这就是为什么这种方法与以太坊本身一样安全的原因。
And the coolest part is that the delegated function implementation, as well as its signature doesn't matter much, from the delegate back end standpoint. You can even decide to implement one "call by signature" function for all other functions that the smart contract supports. Delegate back end just need to know how to call this function, which is solved by providing an off-chain contract manifest for the delegate back end. For example, the argument additionalParams in transferViaSignature can vary and can include anything from this list, if not more: fee, fee recipient address, expiration timestamp, a signature standard used, a signature itself, nonce number or any other unique delegated transaction ID and so on. Regarding the smart contract design, in order to understand why exactly these arguments, read my previous article.
最酷的部分是，从委托后端的角度来看，委托函数的实现及其签名并不重要。 您甚至可以决定为智能合约支持的所有其他功能实现一个“按签名调用”功能。 委托后端只需要知道如何调用此函数，这可以通过为委托后端提供脱链合同清单来解决。 例如，在transferViaSignature参数additionalParams可以变化，并且可以包括从该列表中任何东西，如果不是更多：费，手续费收件人地址，到期时间标记，用来签名的标准，一个签名本身，随机数号码或任何其他独特的委托事务ID和以此类推。 关于智能合约设计，为了准确理解这些论点，请阅读我以前的文章 。
We also want to allow "delegates" to earn something in order to cover their Ether spending, as well as to be profitable. Thus, we have to add a fee, but a much more natural fee than Ether: a fee in the token itself. So that, for example, if you need to transfer 100 tokens, you pay 3 more tokens to the delegate depending on its price and network conditions to perform a transfer, and this should be preserved in a smart contract logic.
我们还希望允许“代表”赚钱，以支付其以太坊的支出，并实现盈利。 因此，我们必须增加一个费用，但是比以太坊更自然的费用：令牌本身中的费用。 这样，例如，如果您需要转移100个令牌，则根据委托人的价格和网络条件向委托人再支付3个令牌，以执行转移，这应该保留在智能合约逻辑中。
后端 (Back End)
All right, now we have a token that allows transferring someone else's tokens by using their signature. Now, the crucial part is to automate the process of requesting and publishing such transactions. And here where our open-sourced back end (and a front end) kicks in.
Below is the sequence diagram describing how front end (client) communicates with the back end from the delegated transaction request to its publishing to the network:
- (hidden on the diagram) The client requests information from the delegated back end to understand which contracts does it support, as well as which functions can it delegate.
- The client requests a particular smart contract's function to be delegated. Most importantly, the back end returns the fees it charges and a data to be signed by the client.
- The client signs the data in their wallet. Signing is a free operation, unlike publishing transaction to the network.
- The client sends their signature back, thus confirming their intent to perform this particular delegated transaction. The back end validates this transaction against the current network.
- Finally, the back end publishes a transaction to the network.
- (hidden on the diagram) The client constantly polls the back end for the delegated request status until it receives a mined status. Note: it is important to poll the back end instead of using a transaction hash to understand when the transaction is mined. It is a very common case when the gas price suddenly increases, and, in order for the transaction to be mined quickly, the back end may republish it with a higher gas price. Though it is currently not implemented, it is very likely to be implemented soon.
(隐藏在图中)客户端一直在轮询后端以获取委托的请求状态，直到接收到已开采状态为止。 注意：重要的是轮询后端，而不是使用事务哈希来了解何时挖掘事务。 当汽油价格突然上涨时，这是一种非常常见的情况，为了快速进行交易，后端可能会以更高的汽油价格重新发布。 尽管目前尚未实施，但很有可能很快实施。
This approach is universal, and only requires the manifest file for the back end to understand how to calculate fees and which signature standard to use on the client side. Here is another visualization of the components of the system and their interaction sequence:
We've provided a comprehensive documentation for this solution. You can check how the back end API is structured, as well as find the token manifest file which describes how to work with a particular token contract. We encourage you to contribute your own tokens there!
And you don't need much setup: it's already there with the universal front end!
前端 (Front End)
Open-sourced front end part of the delegated transactions is the user interface which is set up for every token: just run your delegated transactions back end and you are ready to go!
It is made to be an embeddable widget, which will guide the user through the procedure of sending tokens. You can plug any back end, token or call any token function with it by utilizing additional URL parameters you can specify.
Using this widget, and by implementing something similar to widely used, but not standardized approveAndCall function in your token smart contract, you will be able to call other smart contracts with arbitrary data by paying fees in tokens!
Here is a quick guide for you if you want to play with this UI yourself:
Access the widget via this link.
- It will ask you to switch to the Kovan test network.
Get some test Ether using any available Kovan faucet.
Now, get back to the widget and try to transfer these tokens!
If you open up the browser's developer tools, you may notice that there are a couple of back ends connected by default — they provide the front end with all required information to make a delegated request according to given widget URL parameters. All backends are requested during the widget load and, if any of them can provide a delegation for a particular contract's function, then the widget requests additional information: fees, supported signatures, etc. If there are multiple back ends which can delegate the same contract function, all of them are requested and the back end which provides the best fee will be used for the transaction.
Transaction mining time is seemingly fixed, but it can vary because of the network conditions. The back end uses an actual network fee when calculating the token fee, however, it may change before the user decides to execute the transaction. Thus, the "underpriced" transaction is submitted to the network and can be pending for a while. While the back end is currently not programmed to deal with this case, it might be implemented in future — transactions will be republished with higher gas fees in case of the network fee increases. But, we will also need to count this into the token fee.
事务挖掘时间看似固定，但是由于网络条件的不同，可能有所不同。 后端在计算令牌费用时会使用实际的网络费用，但是，在用户决定执行交易之前，它可能会更改。 因此，“低价”交易会提交给网络，并且可能会等待一段时间。 尽管后端当前未编程为处理这种情况，但它可能会在将来实施-如果网络费用增加，交易将以更高的汽油费重新发布。 但是，我们还需要将其计入令牌费用中。
签名标准 (Signature Standards)
The last question which you may be wondering is — which signature standard to use for your token. There are several available: eth_sign (deprecated), eth_personalSign (note that old Trezor and Ledger produce a different signatures because of ambiguity in a standard, so you may want to include both), eth_signTypedData (deprecated), eth_signTypedData_v3 and so on. I would recommend supporting at least two: ageless eth_personalSign and new eth_signTypedData_v3 (as of 2019).
您可能想知道的最后一个问题是-用于令牌的签名标准。 有几种可供选择：eth_sign(不推荐)，eth_personalSign(注意，旧Trezor和莱杰产生歧义，因为一个不同的签名在一个标准的，所以你可能要包括)，eth_signTypedData(不推荐)， eth_signTypedData_v3等。 我建议至少支持两个：永恒的eth_personalSign和新的eth_signTypedData_v3 (截至2019年)。
The front end is programmed to always prefer the user-readable standard like eth_signTypedData_v3 to any others eth_personalSign. So if your token supports many signature standards, and you added all of them to the manifest file of your token, it will display eth_signTypedData_v3 prompt first.
Delegated transactions are great: they solve one of the biggest problems of blockchain application adoption, which eases the mass adoption of crypto overall. I will put a couple of thesis in a Q&A format here for you to answer the last questions that you may still have after reading this article:
- Our open-source solution is free to use and production-ready, feel free to apply it to your applications or tokens!
- The described approach does not compromise security nor centralization. Think this way: the centralized back end is only a helper for someone who wants to transfer tokens without fee in Ether. If the back end is hacked, or it is just unavailable, there's no problem to interact with the network just as it was before, by paying fees in Ether. As well as the back end cannot harm or trick the user to steal their tokens when a proper signature standard is used (it's up to your token implementation).
所描述的方法不会损害安全性或集中性。 这样想：对于想要在Ether中免费传输令牌的人来说，集中式后端只是一个帮助者。 如果后端被黑客入侵，或者后端不可用，则可以通过在Ether中付费来与网络交互，就像以前一样没有问题。 当使用适当的签名标准时(后端取决于您的令牌实现)，后端也不会伤害或欺骗用户窃取其令牌。
- There is a way to support delegated transactions for existing, already-deployed tokens. However, it requires the additional Ether-consuming step to migrate existing tokens to a new token contract. And, by programming a new token contract properly, as well as designing your application to work with both tokens you can even avoid a need to list a new token on exchanges.
有一种方法可以支持现有的，已经部署的令牌的委托事务。 但是，这需要额外的以太坊消耗步骤，才能将现有令牌迁移到新的令牌合约。 而且，通过正确地编程新的令牌合约，以及将应用程序设计为可同时使用两个令牌，您甚至可以避免在交易所中列出新的令牌。
Read the instructions on how to set up your own back end for a token, and then add it to the URL of your widget (or commit to the open-source repository).
Have a token which already supports delegated transactions? Plug it into our UI with these three quite simple steps: (1) create a manifest for your token and put your token abi file while setting up the delegate back end, (2) run this back end, exposing a public API URL and (3) use URL parameters in a widget to reference your back end or commit it directly to our open-source repository. Read more about it in GitHub's readme file.
是否有已经支持委托交易的令牌？ 通过以下三个非常简单的步骤将其插入我们的用户界面 ：(1)为您的令牌创建清单，并在设置代理后端时放入令牌abi文件，(2)运行此后端，公开公共API URL，并( 3)在小部件中使用URL参数来引用您的后端，或将其直接提交到我们的开放源代码存储库。 在GitHub的自述文件中了解有关它的更多信息。
I hope that was a really helpful piece of information for all the searchers of incredible. Feel free to contact me or fill the issue here if I missed something. Have fun, let the token economy be simple!