Description

See: https://github.com/superfluid-finance/protocol-monorepo/blob/d93b1a743ead8000544596b8565f7a93eea42943/examples/tradeable-cashflow/tradeable-cashflow-truffle/package.json#L19

Components

• Smart Contracts
• Backend Infrastructure
• Frontend Web Interface

Components (other)

No response

Objective:

Create a SharesManager smart contract to manage and compute the shares of advertisers within our advertising auctioning DApp (GDA Super Example). This contract should handle the logic of share assignment, updating, and querying based on the duration and value of advertisements.

Key Responsibilities (Only a suggestion, subject to ideal implementation):

• Manage Share Assignment: Allocate shares to advertisers based on the duration and value of their advertisements.
• Update Shares: Adjust shares when a new advertiser starts streaming funds, ensuring the distribution remains fair and proportionate.
• Track Advertisement Duration: Keep a record of the duration each advertiser's content is shown.
• Share Computation: Calculate the shares for distribution from the GDA pool based on advertising time and value contributed.

Further details:

Contract can keep track of state or it can just provide methods to be called. These methods need to make it as easy as possible for us to update the state of a specific advertiser (share holder). For example: a method updateShares can take as input the address of the advertiser, the number of days they have been advertising and some other inputs to update the state of their current shares. Make sure to take care of edge cases where shares cannot be split, and keep in mind how the GDA pool would interact with these methods.

Feel free to change details of what is mentioned above according to the best way you see fit for the implementation.

TBH it is not a bad security issue. I just wanted to point out that this function does not protect the contract from receiving tokens from someone else since anyone can send tokens via their Metamask to the contract bypassing the revert

money-streaming-intro-foundry/lib was added to .gitignore, but not removed. Should also be removed.

Description

Hi, first of all awesome repo! Thanks for the great getting started experience. As I've been going through things, there are just a few issues such as links from the youtube not going to active pages, deployment arguments supplying 2 when the contract calls for 1, file names missing an "s" during console instructions referencing file scripts/transferInSpreaderToken.js is really scripts/transferInSpreaderTokens.js, and all the scripts not outputting how is expected on georli. Local works as expected and test suite working as expected, am assuming the script files in the examples must have been updated and just documentation wasn't updated to match? 🤷🏼

Can provide more info as needed, just wanted to alert the team incase they know what I'm talking about and is an easy documentation/code sync update.

Components

• Smart Contracts
• Backend Infrastructure
• Frontend Web Interface

Components (other)

No response

Description

Hello fixed error
beginner-examples -> money-streaming ->tokenApproval.js

Components

• Smart Contracts
• Backend Infrastructure
• Frontend Web Interface

Components (other)

beginner-examples -> money-streaming ->tokenApproval.js

Background

Superfluid protocol has the capability of distributed money continuously over time, which adds greatly to the design space of the automatic market makers (AMM).

This issue is created to track the discussions, toy modeling and specifications of different designs we have.

Without Constant Flow Distribution Support

All of these would require IDA to trigger frequent distributions.

With Constant Flow Distribution Agreement Support

Grizzly can be further enhanced with CFDA support in that settlements to downstream will be more smooth over time.

Notes

!IMPORTANT!: Due to the delicate security needs of these contracts, we should not release unverified code prematurely to the public.

Based on several conversations with DevX in the last week, I propose that we remove 1 example, and add 2 new examples which provide developers with an easy way to get started with Superfluid in solidity.

Example to Remove: The Rewards Distribution token

• Callbacks operation is not intuitive
• Example is not often used
• We have a new CFA/IDA example as is
• Causing additional maintenance burden

2 New Examples: Money Router and Token Spreader

These two examples will be created as a part of an effort to build a progressive tutorial for developers new to the protocol.
When a new developer first sees our repo, they currently aren't able to fork an example that implements Superfluid in isolation within a non-super app smart contract. In practice, this is how many hackathon developers build on solidity.

This tutorial will consist of several parts:

1. Learn how to work with the CFA using the Money Router example
2. Learn how to work with the IDA using the Token Spreader example (may need new name @sunnyjaycer 😄)
3. Get an introduction to super apps using the Tradable Cashflow contract
4. Learn about user data and build a simple front end using the NFT billboard example
5. Become a Superfluid expert by mastering the Stream In - Distribute Out Example

We create video guides to accompany each of the 5 above examples. Then, we will place them in a longer guide and single Youtube video or playlist that's similar to what other DevX leaders have done. The following two examples provide an idea of what I'm considering:

• https://www.youtube.com/watch?v=gyMwXuJrbJQ
• https://www.youtube.com/watch?v=nRMo5jjgCr4

The Money Router and Token Spreader contracts should live in a single folder within the examples section of the repo titled 'superfluid-solidity-basics.'
@sunnyjaycer can provide more details on his token spreader IDA example, but the Money Router will do the following:

1. Allow users to call functions to create, update, and delete streams into the contract itself (making use of the ACL to do so)
2. Allow users to call functions to create, update, and delete streams from the contract to other addresses
3. Scripts will be present which allow devs to see how the SDK Core can be used to interact with the contract
4. Full test suite which allows devs to see what a simple test suite looks like when working with the CFA.

The simplicity of these 2 new contract scopes will make them easy to maintain.

cc @JoshuaTrujillo15 @sunnyjaycer @ngmachado - what do you guys think about this?

Code line:

I think executeStartVesting should be replaces with executeStopVesting as it is never used in the contract.

100000000 <- gaslimit set
30000000 <- max gas there can be in a block

Description

TBD...

Components

• Smart Contracts
• Backend Infrastructure
• Frontend Web Interface

Components (other)

No response

References

• superfluid-finance/protocol-monorepo#961

At https://github.com/superfluid-finance/super-examples/actions/runs/5692548322 we can see build succeeded on July 28th.
But there is no locking of packages version so now it uses another version of ethereum-contracts which is incompatible with these exemples so it creates build errors.
I've checked https://github.com/superfluid-finance/protocol-monorepo/releases?q=ethereum-contracts&expanded=false and found that 1.7.1 was the latest version available on July 28th.
So I'm preparing a PR to fix this.

[Docs] - Review and update links, should be pointing to this repo and not the old one.

Summary:

Develop a decentralized application (DApp) using the Superfluid Protocol's General Distribution Agreement (GDA) to facilitate an advertisement auctioning system. The DApp should allow for continuous streams of funds into a pool, distributing half of the incoming funds to the DApp's initial owner and the other half among former advertisers based on the duration of their advertisements. A real-time auction mechanism should enable the highest current contributor to gain advertising rights on the DApp.

Goals:

• Implement a GDA-based pool for fund distribution.
• Enable proportional distribution of funds based on advertising time.
• Create a streaming mechanism for funds that allows for real-time auctioning of advertising space.

Description:

Pool Creation and Admin Setup:

• Develop functionality for any user to create a pool with a specified admin.
• The admin should not be able to assign and revoke units to pool members.
• Stream receivers can trade their shares.

Fund Distribution Logic:

• Implement the logic where 50% of incoming streams are sent to the DApp's initial owner.
• The remaining 50% should be distributed among previous advertisers proportionally, based on the amount of time they advertised.

Advertisement Auctioning Mechanism:

• Integrate a bidding system where advertisers can create a stream to the pool.
• The advertiser with the highest current stream should automatically gain the right to advertise on the DApp.
• Upon being outbid, the previous highest stream is stopped and the user gets proportionate shares for future distributions.

Share Allocation Based on Advertisement Time:

• Ensure that shares are allocated to advertisers corresponding to how long their advertisement was displayed.
• Shares determine the proportion of the 50% fund distribution received by previous advertisers.

DApp Interface:

• Design and develop a user-friendly interface for the auctioning system.
• Display current advertisement, the highest stream, the advertiser's info, and time advertised.

Smart Contract Development:

• Write and test smart contracts to handle stream creation, share assignment, fund distribution, and real-time auctioning.

Security and Testing:

• Thoroughly test the smart contracts for bug/vulnerabilities and ensure robust handling of funds and shares.
• Set up contracts on testnets verify functionality.

Acceptance Criteria:

• A fully functional GDA-based DApp allowing for the advertisement auctioning as described.
• An intuitive UI/UX that allows users to easily participate in the auctioning process and view pertinent information.
• Complete documentation detailing the DApp's functionality, smart contract interactions, and user instructions.

Nice to have:

• The DApp should be scalable to accommodate a growing number of advertisers and increased fund flows.
• The DApp should be aligned with the latest industry standards (Account abstraction, security practices etc.).
• Consider gas optimization for transactions to enhance user experience.
• The DApp should comply with all relevant regulations of the DeFi and advertising space.