Star-wrapper project

[Michael Hartl]

I’m writing with an update on a project designed to make Urbit address space accessible to a wider group of users. Among other things, this involves creating a deeper integration between Urbit and the booming DeFi ecosystem.

For those who don’t know me, I am a galaxy-owner and long-time supporter of Urbit. As part of an Urbit community effort, a group of star and galaxy owners has been working on developing a wrapper contract for Urbit’s non-fungible star tokens. We’re now at a point where we’d like to solicit further input and feedback.

Essentially, the contract allows a holder of an ERC-721 star to deposit it into the contract and receive an ERC-20 (technically, ERC-777) $STAR token in return, and vice versa. These tokens would then be suitable for listing on Uniswap and other exchanges. We’ve posted the draft code to GitHub here: https://github.com/ransonhobbes/stardust

Given the significant implications this potentially has for Urbit as a whole, I wanted to let the dev community know about our progress, and to make a formal request for Tlon to get involved where appropriate. In our view, Tlon is in the best position to make sure this project doesn’t create any unintentional security holes.

As we see it, there are three primary ways that Tlon could provide value:

1. Once we have a live version running on the testnet, the code should be audited. Tlon may be able to help here.

2. We think the interface should run on urbit.org, so as to emphasize that this is the canonical version and to discourage copycats. Tlon may be able to assist in the development of this website to ensure that it works properly and has a UI that matches the overall Urbit aesthetic.

3. Tlon might be able to provide assistance with documentation to make sure the project’s purpose and scope are clear.


We would of course love to have input from anyone in the Urbit developer community. We’re especially interested in finding someone to help develop the website and user interface, which will be an ongoing project once the backend smart contract is fully locked down. Speaking of the contract, if someone is or knows an auditor we’d appreciate an intro. Please reach out directly or respond here with any comments or questions.

Best wishes,

Michael

--

Michael Hartl

michaelhartl.com

[Christian Crawford]

Choice of AMM I think is rather important - Uniswap V2, for example, permanently burns 1e3 liquidity pool tokens the first time liquidity is added. The first adding of liquidity sets the starting price, which is the ratio of the reserves, and mints sqrt(reserve0Added*reserve1Added) lptokens, so 1e3*sqrt(r0/r1) tokens would permanently be lossed.

I think balancer might be a really good choice for this. Firstly, it is able to require lower initial capital requirements through the assignment of weights where weights add up to 1. The price in token0/token1 terms is (reserve0/weight0)/(reserve1/weight1), and so in an efficient market the weights determine the share of total value of the respective tokens in the pool. In addition, it allows managed pools where liquidity providers may be whitelisted and weights can be adjusted over time. This has been used for certain sorts of fundraising schemes where the token being raised starts at a very high weight and the weight is progressively lowered over time such that the price goes down unless there is enough demand to offset the lowering of the weights. Notably, and relevant for us, by assigning a high weight to the $STAR tokens, the amount of ETH or USDC or WBTC or whatever required for a star owner to bootstrap liquidity for their star tokens can be far lower than is necessary for Uniswap. In addition, because of the managed pools and no permanent burning of a share of the LP tokens, no $STAR tokens are permanently lossed, and the star owner may be the sole LP, allowing the profits from sales to be obtained at any time, and notably, the profits are not obtained by selling into a pool(at least not exclusively), but by owning all of the LP tokens for the pool from which $STAR tokens are purchased.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

[Galen Wolfe-Pauly]

Michael, this is fascinating work. Thank you for sharing an update and for getting so involved here.

As you know, Tlon is focused mostly on building Urbit itself, and we don’t give much thought to tokens.  We have typically steered clear of any projects that have to do with transacting Urbit address space. That said, we’ve heard from you and a few others that this is moving forward whether we pay attention or not. Generally that’s a good thing — Urbit is an ecosystem of developers, and Tlon is just one of those; we’re not the final arbiters of what should be done with Urbit. That said, it does appear that this project could have a significant impact on the security of the network as a whole, and so it has become something of an all hands on deck situation. 

Taking your requests in order, our view is the following:

1. If this code is going live, it must be audited. This is crucial no matter who created the code. If you do not have an auditor to do this work, we’ll help find one. If you don’t have the resources to pay for the audit, we’ll contribute. 
   
2. We agree that there should be one canonical trustworthy interface for the wrapper. Copycats are inevitable. If you do not propose a better solution, we would be open to hosting that on urbit.org. As you know, we’re rather picky about UX and design, so if the interface is going to live on urbit.org, we would necessarily be involved with the design. 
   
3. We can also lend a hand on the documentation side for the reasons above. 
   

Generally our take on this work is that it’s a community project, not a Tlon project. The more the ecosystem of developers can do here the better. That said, we’ll fill in the gaps to make sure the network isn’t jeopardized. 

I think I have to read Christian's email again to actually understand it. But the main thing is just that we'll help move this along and make sure it's realized in the safest way possible. Thanks for posting publicly!

[Michael Hartl]

Thanks to everyone for the constructive feedback. It looks like we’re set to continue moving forward with the project. I’ll plan to get in touch individually with those who have indicated a willingness to help.

Best wishes,

Michael

--

Michael Hartl

michaelhartl.com

[Josh Lehman]

The first and second audits have both been completed now, the results of which are attached.

The first audit (the markdown file) didn't turn very much up at all, hence the delay in submitting it here.

The second audit is more interesting and definitely worth a read. Would appreciate Phil's take. 

[Philip Monk]

IMO STR-01 is not an issue because I consider sponsoring a star to be a slight liability if they're not paying recurring revenue, but it's good to be aware of in case someone decides to incorporate "number of sponsored stars" into some algorithmic reputation model.  It's also a good sign they took a broad examination of the contract implications.

STR-02 is a legitimate concern, and they're correct that the Galaxies are the proper deciders of the "exception" of how to recognize that stars are lost and how or whether they should be reclaimed.  Galaxies would only even consider reclaiming a star if it was provably lost, for example if some of the STAR token was sent to the 0x0 address.  They're able to reclaim stars through an upgrade to the Ecliptic even without any changes to this contract, so I wouldn't change anything.

For upgradability, if it became super important to upgrade, it is again possible for the galaxies, through an upgraded Ecliptic, to take the stars in the Treasury contract and give them to a replacement Treasury V2 contract.  While the galaxies should avoid being overactive in governance, IMO this is exactly the kind of thing they should be doing: ratifying exceptions to the normal ownership rules when those exceptions don't violate accepted norms of ownership.

On Fri, Aug 06, 2021 at 4:13 PM, Josh Lehman <jo...@urbit.org> wrote:

The first and second audits have both been completed now, the results of which are attached.

The first audit (the markdown file) didn't turn very much up at all, hence the delay in submitting it here.

The second audit is more interesting and definitely worth a read. Would appreciate Phil's take. 

On Wednesday, June 2, 2021 at 3:35:29 PM UTC-7 ~ticryn-ritsyd wrote:

Thanks to everyone for the constructive feedback. It looks like we’re set to continue moving forward with the project. I’ll plan to get in touch individually with those who have indicated a willingness to help.

Best wishes,

Michael

To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@urbit.org.

--

Michael Hartl

michaelhartl.com

[Christian Crawford]

https://twitter.com/bantg/status/1432278235631529989

yeah i had concerns with erc777, seems not great

https://medium.com/consensys-diligence/uniswap-audit-b90335ac007 it's been known about for a while
> Every ERC-777 token should have a callback to the spender before the balances are changed and to the recipient after. That allows everyone to make malicious reentrancy to an exchange contract with ERC-777 token.

it adds a lot of complexity that makes it not safely composable with defi whatever stuff and lord knows thatll happen when the degens catch word of it

On Saturday, August 7, 2021 at 12:48:02 AM UTC+3 phi...@tlon.io wrote:

IMO STR-01 is not an issue because I consider sponsoring a star to be a slight liability if they're not paying recurring revenue, but it's good to be aware of in case someone decides to incorporate "number of sponsored stars" into some algorithmic reputation model.  It's also a good sign they took a broad examination of the contract implications.

STR-02 is a legitimate concern, and they're correct that the Galaxies are the proper deciders of the "exception" of how to recognize that stars are lost and how or whether they should be reclaimed.  Galaxies would only even consider reclaiming a star if it was provably lost, for example if some of the STAR token was sent to the 0x0 address.  They're able to reclaim stars through an upgrade to the Ecliptic even without any changes to this contract, so I wouldn't change anything.

For upgradability, if it became super important to upgrade, it is again possible for the galaxies, through an upgraded Ecliptic, to take the stars in the Treasury contract and give them to a replacement Treasury V2 contract.  While the galaxies should avoid being overactive in governance, IMO this is exactly the kind of thing they should be doing: ratifying exceptions to the normal ownership rules when those exceptions don't violate accepted norms of ownership.

On Fri, Aug 06, 2021 at 4:13 PM, Josh Lehman <jo...@urbit.org> wrote:

The first and second audits have both been completed now, the results of which are attached.

The first audit (the markdown file) didn't turn very much up at all, hence the delay in submitting it here.

The second audit is more interesting and definitely worth a read. Would appreciate Phil's take. 

On Wednesday, June 2, 2021 at 3:35:29 PM UTC-7 ~ticryn-ritsyd wrote:

Thanks to everyone for the constructive feedback. It looks like we’re set to continue moving forward with the project. I’ll plan to get in touch individually with those who have indicated a willingness to help.

Best wishes,

Michael

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

--

Michael Hartl

michaelhartl.com

[Josh Lehman]

The third and last audit, this one from Sigma Prime, has been completed. See attached report.

[Vinney Cavallo]

Hey all, this is my first post here.

I wonder if people in this thread are aware of the idea to tokenize Galaxies? It seems to be in its infancy, discussed here for the first time, as far as I know: https://www.youtube.com/watch?v=OiYKw9x2_GA

PointDAO has acquired ~wen as of September 7th.

Vinney

https://vinneycavallo.com

[Galen Wolfe-Pauly]

Hi Vinney,

I've been really enjoying following the PointDAO developments from a distance. I'm not completely sure where it's going, but that's what's interesting and exciting about it. I know lots of other people at Tlon are aware of it as well. I think everyone I've talked to about it finds it pretty exciting.

I think the stardust project and the PointDAO project are potentially cooperative in an interesting way, since they each tokenize different parts of the address space. I've always kind of expected that different forms of governance would emerge layered on top of the simple one-vote-per-galaxy design. It's nice to see that emerging on its own. 

G