feat: proposed fungible token trait

[hstove]

Included is a proposed standard and trait for fungible tokens on the Stacks blockchain.

This addresses #1 and stacksgov/grants-program#44

cc @psq - almost all of this code comes from your work, and you deserve all the credit for this. Please request any changes you'd like to see, and I will include them.

[psq]

there were some discussions on adding an icon for the token. One of them was to add a function such as:

;; Icon URL, limited to 2048 chars
    (icon-url () (response (string-ascii 2048) (tuple (kind (string-ascii 32)))))

The problem, though is that urls come and go, so this may not be ideal. However, we now have attachments, so that would be one way to do this. Or we can use IPFS/Filecoin/Skynet urls which should be more permanent.

Furthermore, we don't have optional functions like Solidity has, so my proposal would be to have optional traits that may not always be implemented (whether a contract support these optional traits can be done by parsing, and would be enforced at runtime by failing to meet the trait requirement.

So the icon function would be in such an optional trait:

(define-trait ft-trait-icon
  ;; Icon URL, limited to 2048 chars
    (icon-url () (response (string-ascii 2048) (tuple (kind (string-ascii 32)))))
)

One suggestion from @jcnelson was to return a (on-chain) BNS name instead of a url. Or make the url scheme be more like a more general uri that supports all possible ways to address the content.

[hstove]

Yeah, I think the icon problem is important but perhaps best to not be in this trait to keep things simple. There are also problems around icon URLs - potential for abuse (both via content and privacy), etc. If I was going to use this in a wallet or app like Swapr, I'd pull the icon from a registry, with whitelisted icons. See also https://tokenlists.org , used by Uniswap and others. Worth noting that name/symbol could be abused, too.

[friedger]

What about the error codes, should we use uint or a more useful description like proposed in #3

[friedger]

The signature should have a sender because the sender can be the tx-sender or the contract-caller.

[friedger]

The order in the native function is amount sender recipient. To make it easier for clarity developers, I suggest to use that ordering of the native function.

[psq]

I had not needed to set a sender, but I suppose this is a valid point

[hstove]

Thanks Friedger, I will change this based on that suggestion. I am actually not sure how authorization works in ft-transfer - is there any? The docs don't mention it as an error code, so likely not. We should add a note about authorization, and add it as boilerplate in the example repo. I'll also add tests around authorization.

Error codes will be fleshed out, as well.

[jcnelson]

There isn't any built-in authorization in ft-transfer? (or nft-transfer? for that matter). The contract that declares the token is solely responsible for ensuring that the caller is permitted to use the given sender argument. Note that this is different from stx-transfer?, which does require that the sender argument is equal to the calling context's tx-sender.

[jasperjansz]

Can't tell from the code if this is included, but: Should the name or symbol be globally unique? Imagine two different FT's with the same symbol "Foo". If none of the human-readable strings are globally unique we'd be back to using the fully-qualified name to differentiate between tokens.

On the other hand, this could also lead to squatting, so I'm not too sure about it.

[hstove]

@jasperjansz , this is not in the spec, nor is it really possible to address in this spec. I linked up above, but there is almost no way around having some kind of registry for tokens, even if on-chain. For example, a token registry contract could be fully permissionless, and enforce unique names within that registry.

Squatting is definitely something you wouldn't want. If you want human-readable names and global uniqueness, which is obviously good, then BNS is probably a good option.

[stackatron]

Same thing was on my mind as @jasperjansz. The scenario where an end user really needs to verify which token is which is also probably the scenario where that token is not whitelisted yet. If so, does that mean contract address will become the de facto canonical identifier? Pretty easy, not super intuitive, and I wonder if we can do better.

[hstove]

If so, does that mean contract address will become the de facto canonical identifier?

Yes, however, we can and should improve on that. I just think it's out of scope for this SIP. This is what registries are for. Uniswap uses https://tokenlists.org, and we can utilize on-and-off chain registries. Such registries could use BNS, too. Either way, you need some de-facto trusted source for "this contract identifier is the true $JEFF token".

[jcnelson]

Would you consider adding @psq as a co-author of this SIP?

Also, this paragraph would belong in the Related Work section, since it's describing a similar system.

[hstove]

Of course I would be more than happy to add @psq! Per SIP-000, I need to add an email address - do you have one you're willing to share, Pascal?

[jcnelson]

Lots of interesting things happening here. Keep up the great work everyone!

[hstove]

I've also just rebased my branch on top of the hstove-feat/sip-10-ft branch in this repo

[friedger]

@hstove Can we change get-balance-of to get-balance ?

[hstove]

We have contracts that are aiming to go on mainnet within a week, that have already dealt with lots of thrash due to change in the SIP. I personally would rather keep the SIP as-is than go through another round of changes.

[friedger]

What is a week compared to eternity?

The request is months old.

[hstove]

Personally, I'm fine with the change, and I see the reasoning. I honestly am not sure how best to move forward on this. Am I supposed to be a dictator or is this a group decision? I certainly want it to be a group decision based on folks who have contributed in any way on this thread.

My only concern are the folks who are seriously close to shipping. Devs working on tokens: @whoabuddy @psq @philipdesmedt @pooleja. Also @aulneau who has a PR for supporting SIP 10 in the wallet

[Zk2u]

Devs working on tokens: @whoabuddy @psq @philipdesmedt @pooleja. Also, @aulneau who has a PR for supporting SIP 10 in the wallet

Nah we should be okay. to be honest, it's a very minor change, and we can change it in a few cmd+h's and a single commit.

[hstove]

Ok, in the interest of time, let's just make the call now. I'm deploying the new trait at the moment and will push the changes soon

[hstove]

New traits deployed: SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard
testnet: STR8P3RD1EHA8AA37ERSSSZSWKS9T2GYQFGXNA4C.sip-010-trait-ft-standard

[philiphacks]

my 2 cents: this change was useless and nitpicking.. I can give the same argument for get-balance-of.. I like the -of since it is more expressive...

let's just not change the SIP anymore now, since this is becoming annoying :) let's ship

[jcnelson]

I honestly am not sure how best to move forward on this. Am I supposed to be a dictator or is this a group decision?

In general, it's best to resolve all points of contention within the same SIP. If we later regret the decisions made for the fungible token trait, we can always submit a new SIP that supersedes this SIP after this SIP activates (or gets rejected).

In this specific case, it looks like the point of contention is in the name of a function. I recommend that in such cases, the SIP author just pick a reasonable name and ship it if no resolution can be had.

[whoabuddy]

Makes sense to me, and I'm less picky about the name, will update things on our side to match the current standard as it sounds like this is the final decision.

[314159265359879]

New traits deployed: SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard
testnet: STR8P3RD1EHA8AA37ERSSSZSWKS9T2GYQFGXNA4C.sip-010-trait-ft-standard

@hstove do you want to redeploy this to testnet now that it is restarted?

On the main page it still shows the link to the outdated trait with get-balance-of that may lead to mistakes. Want to update that? Or has the SIP since been activated when I search for "SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard" on clarity-search I find two mentions (a) wrapped-nothing-v8) and (b) btc-ft-swap, I do not understand that second one so I don't know if that is implemented correctly, @jcnelson you help to analyze if (b) is correct?

I do see recent contracts that look like they try to implement the SIP010 trait but still use get-balance-of for example this one 11 days ago: https://search-clarity.dev/contracts/SP23DAB333A5CPFXNK13E5YMX1DZJ07112QNZEBCF.tokensoft-token-v3a this one did not show in the search because they deployed their own copy of the trait which is actually an outdated one (with get-balance-of) @psq is probably using it for testing.

Looks like 1 max 2 down, and at least 1 to go for activation.

[whoabuddy]

Noting that MiamiCoin will support the mainnet trait tomorrow, and we have a version of SIP-010 deployed to testnet since we couldn't find the original (linked below):

https://explorer.stacks.co/txid/0x08cb05b2ecc3ffc67d5391d338314a89d53818917c6ba42090fe1a02681d3620?chain=testnet

@friedger also deployed one, but it is named slightly different and doesn't support the optional memo. Didn't notice that until just now.

https://explorer.stacks.co/txid/ST2PABAF9FTAJYNFZH93XENAJ8FVY99RRM4DF2YCW.ft-trait?chain=testnet

It's definitely hard to find these if you don't know where they are! There should be a process to redeploy these from the same address or at least the same/correct version upon chain resets for testnet.

[jcnelson]

Something interesting happened. A lot more token contracts seem to be implementing SP23DAB333A5CPFXNK13E5YMX1DZJ07112QNZEBCF.sip-010-v0a.ft-trait instead of this SIP's trait. @hstove what if this trait became the standard instead, since it's getting traction? Would it be reasonable for people who have implemented this SIP's trait to implement a proxy contract that implements this other trait?

[lgalabru]

Unless I'm missing something and assuming clarity-search is working correctly, all the contracts implementing the trait SP23DAB333A5CPFXNK13E5YMX1DZJ07112QNZEBCF.sip-010-v0a.ft-trait are contracts deployed by the same owner.

[jcnelson]

Ah, you're right @lgalabru. Should have noticed that. @hstove please disregard the above.

[314159265359879]

It looks like clarity search is not showing recent contracts to mainnet. It has been on 145 contracts for quite a while now. With the miamicoin contract we now have three contracts that use the trait, that activates it right?

…

On Tue, 31 Aug 2021 at 22:03, Jude Nelson ***@***.***> wrote: Ah, you're right @lgalabru <https://github.com/lgalabru>. Should have noticed that. @hstove <https://github.com/hstove> please disregard the above. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH6QUB3RRWBZUQVAZWUWN63T7UYRTANCNFSM4WSVYRAQ> .

[whoabuddy]

Seconding that question - @jcnelson can we consider SIP-010 activated?

Also noting that when I search for the trait via clarity-search, the miamicoin-token contract isn't coming up, but you can see we impl-trait on line 20 of the source.

https://search-clarity.dev/?declare=&use=&search=SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard

https://explorer.stacks.co/txid/0xc513b769c261233865c43f101438bd6359636ecacfe34576e6424d6c2629174e?chain=mainnet

[jcnelson]

Yes! Looks like the activation threshold has been reached! Merging.