Sae’Von Springer | Mysten Labs | Native Assets

New song dropping on @soundxyz_ at midnight. 👀 sound.xyz/saevon/glass-h…

We're expanding TradePort beyond NFTs with the launch of our DEX Aggregator to unify all Sui digital assets in one place. Our team has been building on Sui since day one, and we are excited to offer a robust and intuitive trading experience designed for the Sui Community!

This is Year Zero of the machine economy. Agents paying agents. Quintillions of transactions. Trillions of dollars flowing at the speed of intelligent systems. Today we're launching Beep, the financial protocol for autonomous agents, on @SuiNetwork. 🧵

@StevesMisfits Can confirm Steve is solid. He's got some crazy drip, too. 👀

(1/5) Steve's Reward Seasons It’s time for the most revolutionary reward system I have ever invented, I am officially launching …drumroll… Steve’s Points (Yes!) Don’t get your hopes up... we know nobody gets rich on Misfits. But no reason we can't have some fun going to zero. Thread continues👇

We are live! May or may not be some alpha shared. 🤷🏿‍♂️ x.com/i/spaces/1MYGN…

AI builders shouldn’t have to choose between decentralization and performance. That’s why @YottaLabs is integrating Walrus as its dedicated data layer - powering cost-efficient, lightning-fast infra for massive AI workloads. Learn more 👇 walrus.xyz/blog/yotta-lab…

Fireblocks is the alpha. 🔥 The next wave can now commence. 🌊 IYKYK. 😉

We are live x.com/i/spaces/1lDGL…

We are live! x.com/i/spaces/1BdGY…

We need more buybacks in the ecosystem. Many projects are making a lot of $$$ with no revenue share to token holders. How do we change this?

@Stoicsui @AveryChing @WalrusProtocol Thank you @Stoicsui ! I'd imagine there's some more nuance this table doesn't show that @AveryChing could better elaborate on. 😉

@NativeAssets @AveryChing @WalrusProtocol Their white paper highlights this already ser

Great day @AveryChing ! Would you say that @WalrusProtocol is a fair comp in terms of the problem space Shelby is aiming to address & how it achieves that goal? Would you be open to sharing some specifics as to where the two protocols vary in capability, performance and architecture? Many of us are quite eager to learn more. 🙏🏾

Congrats to @arttoo_official on their launch! 🎉

No idea how this connects into the whole @Claynosaurz game world, but the claim process was fun, and Sui was surprisingly smoother than I expected. Excited to see how the game world and mechanics would look like!! Hopefully caters mainly to crowd outside of the crypto world.

"It's not DeFi that will bring billions to Web3. It's Entertainment" - @Cabanimation 🤯 Do y'all know who Mediawan is?!? ChatGPT it. With haste! THEN, MAYBE you'll grasp the gravity. Clayno is delivering like NONE OTHER!!! 😤 Fade at your own risk ...(NFA 😉)

The most important mint ever??!! Might just be! Pull uppp! x.com/i/spaces/1vAGR…

"We've now trauma-bonded." - @NativeAssets It's time to unite and avenge $Sui folks!

This TOO shall pass! 🌊 🌊🌊

In light of recent events, I want to highlight a few key principles about how we think about smart contract development in Move. First, it’s important to reiterate that this was not an issue with Move itself but rather a domain-specific bug. These types of bugs can exist in any language and is why exhaustive test coverage, audits, and tools like @AsymptoticTech’s Move prover are so important. In fact, one of the most slept-on features of Move 2024 was the addition of macros. Macros have completely revolutionized the ease of writing tests in Move. If you don’t believe me, take a look at any of @themoveguy‘s Move tests. New tools like this are great but are only impactful if you incorporate them into your Sui smart contracts – for this reason I have personally dedicated a lot of time to revamping our internal Move testing infrastructure using these newer tools. Now let’s get in to the purpose of this post. How you design your smart contracts should not be taken lightly – real people's money is at play. The way Move was designed (object model, type system, ability modifiers, ownership model, … the list goes on) helps alleviate certain bugs but no one language is free of bugs altogether. You must spend a lot of time and consideration on every aspect of your smart contract to make sure it remains as secure as possible. During the designing phase of every product, we always discuss the many ways to design a product [on-chain] and the different trade-offs each design has in terms of security vs other factors. As I’ve mentioned in one of my medium posts: At @AftermathFi, our users’ security is always the foremost priority throughout the design, development, and rollout of all of our products. Below I’ve listed a few design considerations we had and the choices we made that focused on the safety of our users’ funds. Afterburner Vaults. One of the most requested features we’ve received since the launch of our original Afterburner Vaults was auto-relocking of user positions. This is a tremendous UX improvement over requiring users to relock themselves at set intervals so why haven’t we provided this: we simply can’t. With the design of our Afterburner Vaults, we favored security of user funds above all else. Because of this, when you deposit funds into our Afterburner Vault, your funds are wrapped by a custom object and transferred directly back to you. This means that you, and only you, have access to your liquidity (should it be any other way?) – the Afterburner Vault does not pool together liquidity nor can any other address, ourselves included, interact with your deposited funds. This is very important as now it means only you can invoke transactions that interact with this object. In the case that you want to extend your position’s lock, only you can initiate a transaction to do so. This all comes down to Sui’s unique object-centric data model and the ownership properties associated with objects. In the case of our Afterburner Vaults, there existed a spectrum of implementations with competing security vs convenience properties. We’ve chosen the implementation that best favors security of funds as that is what matters most. With all of this said, we have been able to replicate auto-relocking on the newest version of our Afterburner Vaults while still preserving the same design and safety I just mentioned. This way you get the best of both worlds! Shared Custody Pattern. I’ve already dedicated an entire medium post to this pattern but it is too important to not mention here. There are a few domains wherein a user requests that an action be performed on their behalf with their own funds. In our case, these domains are dollar-cost averaging (DCA) and limit orders (LO). The way that you implement a shared custody model has a large impact on the accessibility of your funds and thus their security. We’ve utilized a 1-of-2 multisig, adding complexity on our part not yours, to provide the most strict level of security around your funds. At any moment, the number of actors that can interact with your funds is deterministic; for example, your orders are soulbound to the multisig address until either the order is executed–at which point the resulting funds are sent to your address–or the order is canceled–at which point the underlying funds are returned to your address. What is important is that:   i. At no point can a third-party access the order that holds your funds, and ii. The exact action set that can be performed on your order is static. Again, we were faced with a spectrum of implementations that contrast security vs convenience and we picked the implementation that provided the highest level of security for you, our user. Hot Potato Pattern. With any DeFi aggregator, you are composing transactions across a series of third-party contracts. In our DEX aggregator’s case, we are chaining together swaps from many spot-trading venues to perform an asset -> asset swap. The number of integrated protocols in unbounded, as a new AMM can always be released tomorrow, and we must be able to support it while maintaining the intra-route safety of our user’s funds. There are a few ways you can manage this every growing number of integrations, again creating a spectrum but this time of security vs package maintenance. The design we went with was to whitelist the third-party integrations we have, thus removing the ability to inject a malicious spot-trading venue. At the start of a route, we wrap user funds into a custom hot potato object and use it during the route to enforce a safe flow of funds through our whitelisted venues. Not only does this provide safety on the routed funds but it also assures legitimacy on all volumes we report; event output is obtained from this hot potato and can only be obtained through a direct route of funds through the trusted, whitelisted trading venues. The above are only a few examples of the design considerations we faced with our products; it's not even the full list for each product mentioned. When designing any smart contract, you are constantly faced with different design questions that can affect the safety of your product. It is always important to put in the effort to ensure you are always doing best for your users.