[Application] LaughStorage staking tool

[martapiekarska]

New application received from @26dos

Name of the Pathway

LaughStorage staking tool

Description of the Experiment

RFA: Automated - Client staking
Pledge Logic:

A. Public Dataset:

1.Submit Application Form:
The maximum size of a single application form is 2PB.
The application form should contain complete information and substantial sample data.

2.Allocator Review:
The allocator reviews the application form. Upon approval, based on the customer scale, 10-50TB will be allocated for the Service Provider (SP) to perform encapsulation verification.

3.Data Verification:
The SP downloads and verifies the public dataset. If the data content and node match the application form, the customer is notified to proceed with the pledge.

4.Client Pledge:
The client pledges FIL based on the application amount. The maximum application amount is 2PB, and the client must pledge FIL corresponding to the remaining balance in a single transaction.

5.Signing and Encapsulation:
The allocator signs off, and the SP performs the encapsulation.

*Pledge Cycle:
The pledge cycle for public datasets is 20 days. The rate is 10TB = 1 FIL, and the pledge is automatically returned to the pledge address upon maturity.

6.Reapplication:
If the client has more data, they can submit a new application form (each form cannot exceed 2PB). Trusted clients can skip the review process, but any updates must be disclosed in advance.

B. Private Data:

1.Submit Application Form:
The maximum size of a single application form is 1PB.

2.Allocator Review:
The allocator reviews the application form, focusing on verifying the customer's identity and the corresponding SP information.

3.Client Pledge:
Upon approval, the allocator notifies the customer to pledge the requested amount.

4.Signing and Encapsulation:
The allocator signs off, and the SP performs the encapsulation.

*Pledge Cycle:
The pledge cycle for private data is 40 days. The rate is 10TB = 1.5 FIL, and the pledge is automatically returned to the pledge address upon maturity.

5.Reapplication:
If the client has more data, they can submit a new application form (each form cannot exceed 1PB). Trusted clients can skip the review process, but any updates must be disclosed in advance.

C.Penalty Logic

I. Automated Penalties (Automated staking token deductions through smart contracts)
1. When more than 50% of the encapsulated nodes have a 0% retrieval rate, 10% of the current staked tokens will be penalized.
2. When the average retrieval rate of the encapsulated nodes is lower than 30%, 10% of the current staked tokens will be penalized.
3. When data sharing occurs, 10% of the current staked tokens will be penalized.

II. Manual Penalties (Deductions through calling smart contract API interfaces)
1. When the Allocator administrator reviews non-compliance, they will make their own judgment and deduct the staked tokens.

III. Manual Return of Staked Tokens
1. When the Allocator administrator finds an incorrect deduction of staked tokens, or when the applicant successfully appeals, the staked tokens will be returned.

Due diligence and other abuse prevention mechanisms that are used

Automatically binds the client's wallet address, equivalent to automated identity authentication. The requirement here would be that the client needs to stake a certain amount of FIL up front to receive the DataCap. The allocation size is dependent on how much they choose to stake.

What is the definition of success

The customer pledges the corresponding amount of fil in advance, and I only need to sign according to the qualified report, and I can repeat this operation

OKRs and other metrics that will be tracked

Success metric: Proof of Payments from clients,Success metric: onchain report of data onboarded,Data Compliance: Data Samples,Data Compliance: Manual report,Compliance: CID report.

Milestones and Development Plan

staking smart contract is done, next steps we will develop a smart contract to automatically distribute data cap base on our logic.

Github repo with the code

https://github.com/26dos/Laugh-Storage-staking-tool

Wallet associated with the allocator (to receive DC)

f410fk3m5nykp5ykl65ytletldbmvflhkta2lbgdhnga

Auditor that will be used

semgrep, website: https://semgrep.dev/

Have you received DC via EPMA before?

No

Do you agree to present a final report at the end of the experiment?

Yes, I agree

Links to previous experiments

[martapiekarska]

Results of Automated verification

Duplicate Submissions?

False

Past Github Activity

📘 GitHub Activity Report

• Repo: 26dos/Laugh-Storage-staking-tool
• Total Commits: 2
• First Commit: 2024-09-27
• Last Commit: 2024-10-12
• Time Span: 16 day(s)

Overlap with Past submissions

False at

[martapiekarska]

KYC Verification Needed!

Please proceed to KYC verification https://verify.didit.me/session/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NDQ4MDk3MDgsImV4cCI6MTc0NTQxNDUwOCwic2Vzc2lvbl9pZCI6IjkyMDlhNDhjLWE1ZDYtNGUwYi05YzJlLTJhOGZhZDYzMDcwZiJ9.YQbzh0o6NgdzRVS8DvIdhdk1aVc9kM9q6bovqIb6sRs

[martapiekarska]

@26dos thank you for your application. There are a few things we need to tackle:

1. Your repository has a single meaningful commit from over 6 months ago with no further development. One of the rules of our pathway is only giving DC to repositories actively worked on. This is also because trying to understand the process of writing this code, changes to it etc is v hard when you have a single commit
2. The auditor you named does not offer a Smart Contract audit, neither it is actually doing audits - as far as I can tell it is an automated tool to do static code analysis.
3. The README provides basic compilation instructions but lacks detailed information about the tool's functionality, usage examples, or the specific problems it addresses. Comprehensive documentation is crucial for understanding and effectively using any software tool.

More precisely, there are some concerns I have about the code:

• You use bind.NewKeyedTransactorWithChainID which implies it expects a raw private key in code or config.: There's no indication that the private key is encrypted or stored securely. Hardcoding or loosely storing a private key is a major red flag.
• User inputs (flags, addresses, amounts) are passed directly into transaction constructors and contract calls. No validation or sanitization = possible unexpected behavior or misuse.
• Error handling is inconsistent - some operations check err != nil, others skip checking entirely. For instance, contract method calls or balance fetches that fail might just log the error but proceed anyway — risky in financial ops.
• There are zero tests. That’s not inherently insecure, but it's concerning for reliability. With smart contract interactions, you should mock blockchain responses and ensure logic behaves safely.

I would suggest you should work further on other elements of this allocator, not just the smart contract and come back to this issue when you have a fully built POC.

[26dos]

Hi @martapiekarska ,

As an active developer in the Filecoin ecosystem, I’d like to share some feedback regarding the current Fil+ process—particularly around the automated allocation track. Please note that this is just constructive input from a contributor who is deeply engaged and invested in building for the network.

1. Longstanding Application with Little Guidance
Our Laughstorage staking tool has been under review for almost one year. During this time, we’ve made consistent efforts—via GitHub and community calls—to push the product forward. Except for feedback from Watchdog and an early outreach from Kevin to the technical team to review our smart contract, we’ve received no clear direction on how to proceed.

2. Development Was Slowed by Lack of Feedback
Indeed, our smart contract was last updated 6 months ago, and we also shared a video demo back then. The reason for the lack of continuous commits is simple: without timely and specific feedback, it has been hard to know what exactly is expected. If we had received more guidance, we would have iterated much faster.

3. Changing Requirements & Lack of Clarity
The expectations around what a submission to this automated track should include were not clearly defined at the outset. Requirements like a fully-featured tool and audit-level security were only recently communicated. We absolutely agree that these are important, but such requirements should be transparently shared from the beginning so teams can build accordingly.

That said, we appreciate your recent comments and take your feedback seriously. The issues you flagged—especially around key handling, input validation, error management, and the lack of tests—are valid. We’re already working to address them.

Our Current Architecture for a Full PoC

We’ve now finalized the structure for a working Proof of Concept, and would love to get your thoughts on the flow:

    1.	User submits an application via the Laughstorage allocation channel.
2.	Laughstorage admin performs KYB/KYC verification.
3.	Once verified, the client stakes tokens and becomes eligible for DataCap allocation.
4.	The smart contract fetches CheckBot review results and returns data to the admin via CLI.
5.	Admin reviews CheckBot data and makes a pass/fail decision via CLI.
6.	Based on the admin’s command, the smart contract either:
•	Proceeds with the DataCap allocation, or
•	Halts future rounds of allocation.
7.	The smart contract monitors DataCap usage to determine whether to refund or deduct staked collateral.

This means both staking and allocation logic are handled securely on-chain.

A Note on EPMA Goals

As we understand it, the EPMA program was designed to:
	1.	Lower the barrier to entry for pilot allocators and encourage experimentation.
	2.	Use automation to streamline the application and review process.
	3.	Build in safeguards to prevent misuse of the system as a shortcut to free DataCap.

If these goals hold true, then requiring applicants to deliver a fully-featured and secure product before EPMA testing contradicts its spirit. EPMA should be a safe space to experiment, discover flaws, and iteratively improve tooling—not a gatekeeping mechanism.

Final Thoughts

We were one of the first teams to step up and begin building tooling for automated allocation using smart contracts. Unfortunately, due to unclear requirements and delayed responses, our application has been pending for nearly a year.

We respectfully suggest that the EPMA process for automation be accelerated to better support early builders. We will take one week to revise the code, address all the issues you mentioned (security, testing, key handling, etc.), and begin internal testing. At that point, we’d like to move forward using the 1P datacap to validate the process.

Meanwhile, we are actively building the full PoC architecture as described above. By the time the EPMA experiment concludes, the product will be in a much more complete and mature state.

Thank you again for your thoughtful review—we genuinely hope to contribute to the growth of the Fil+ program through transparent, secure, and collaborative development.

Best,
Nina
Laughstorage Team

[martapiekarska]

Hi @26dos /Nina
I appreciate your feedback. As you know FIDL is not responsible for the governance of Fil+ and we took on the management of EPMA as a was to unlock the experimentation and allow for faster testing. So, FIDL is not really able to address many of your comments, even if I sympathize with it.
That being said, the rules under which this pathway was accepted by the gov team, require to have active development and code ready for testing, not just an idea that needs further development. So in order to proceed with your application, we will need to see code that executes the plan you suggested and address the feedback from my previous response.
Good luck!
mpg

[26dos]

@martapiekarska Appreciated! I understand!
I will let you know asap when we ready.

[26dos]

Hey @martapiekarska
We’re transitioning from a backend-based signature mechanism to a fully automated DataCap allocation channel.

To move forward, we’d like to request access to the smart contract code (or relevant module) that governs current DataCap distribution. Specifically, we’re looking for the Verified Registry Actor implementation or any automation-related components that manage verified client allocations.

Could you kindly share the relevant contract code or point us to the latest repository? Thanks a lot for your support!

[martapiekarska]

Cross posting from Slack DMs for transparency and archival

I’m writing to follow up on the Experimental Allocator tool we’re building under the Filecoin Plus staking initiative for LaughStorage. This is the GitHub issue where the application was initially submitted:
👉 #12

08:32
The original developer for this project has since been replaced, and I’m now taking over the full development process. Our team lead, Nina, suggested I reach out to you directly to discuss the full MVP scope and possible funding support.
08:34
I also saw from the Allocator Tech Blog (link) that there may be an opportunity to apply for support funding. Given that the MVP is now officially required and we’re expanding development beyond the initial plan, I would like to request funding assistance to ensure timely delivery.
At this point, I’ve already completed the design and deployment of the staking smart contract, as well as the front-end interface. The automated DataCap distribution logic and additional tooling integrations are in progress — I’ll be sharing these components with you shortly.
blog.allocator.techblog.allocator.tech
Request For Allocators
As we described in a previous post, there are two ways of becoming an Allocator - either you respond to this RFA or propose your own, novel ...
08:34
Please let me know if you’d like a more detailed breakdown of the MVP scope or budget. Thank you very much for your support!
08:49
August
Hey Marta, here's the Xmind of our mvp architecture.
image.png

image.png

08:52
https://laughstorage-staking-tool-wga1qdym.4everland.app/ here's the test link.
laughstorage-staking-tool-wga1qdym.4everland.applaughstorage-staking-tool-wga1qdym.4everland.app
Laughstorage staking tool
Laughstorage staking tool
10:35
MPG
Thank you, let me discuss it with the team
10:42
August
Thank you. Our team is waiting for instructions. We need to see if this product has the funds and potential to continue. We look forward to your reply!
16:09
MPG
Dear
@august
thank you for reaching out. We do not run a grants program for the allocator development. You can design the allocator in a way that would allow you to charge for the service and that way run it as a product, this is in line with the program design, and encouraged by the team.
Additionally the design document isn’t enough to qualify for the experimental metaallocator, there needs to be a history of development and more details: see my comments on your application.
Once there is more in, you can always try applying for a ProPGF or other Filecoin grants, but that won’t be coming from FIDL. We are considering/planning to run an invited workshop with some prizes for the best ones and I’ll be sure to invite you to that when/if it happens
07:04
August
Hi
@mpg
If I want to use this contract allocation in my code, do I need to redeploy all the contracts myself?
Or do I only need to become an allocator in the fidl allocator contract to call the client contract?
https://github.com/fidlabs/contract-metaallocator/blob/main/src/Allocator.sol
07:09
August
I have completed all the content I developed, and the only thing left is to allocate the dc through smart contracts. If this succeeds, it will be a new form! Looking forward to your reply!
16:21
August
Hey there, I just wanted to follow up — at this point, the only remaining part of my development is the actual allocation of DC through smart contracts. Every additional day of delay adds significantly to our cost, so I’d really appreciate your guidance on how best to proceed with the contract setup.
Would you be able to provide some direction on whether I should redeploy everything myself, or if there’s a way to simply become an allocator within the existing FIDL allocator contract to interact with the client contract?
Looking forward to your advice — it would mean a lot at this final stage.
18:07
MPG
I am quite confused whjat you are trying to develop.
18:15
MPG
You can apply to test your automated allocator through the experimental pathway metaallocator. https://www.fidl.tech/news/experimental-pathway-metaallocator
Interacting with client smart contract is used for existing manual allocators who interact with their clients and isn't an automation of how DC is allocated but it is a method of managing DC in a safer way - the client specifies which SPs they want to work with and the allocator sets up an allowance for only that wallet to claim DC. https://www.fidl.tech/news/improvements-to-datacap-management
The contract you linked to is a contract that is used to deploy metaallocators (as the name suggests). If you are confused on the nomenclature you can use https://blog.allocator.tech/2024/04/allocator-tech-blog.html
image.png

image.png

fidl.techfidl.tech
Experimental Pathway Metaallocator
The Filecoin Plus (Fil+) program is adding a long awaited Experimental Pathway Metaallocator. Over the past year, the governance team at Fil+, with help of the community, including FIDL, has been working to streamline Datacap allocation by moving toward a Pathway Metaallocator model—a more (95 kB)
https://www.fidl.tech/news/experimental-pathway-metaallocator

fidl.techfidl.tech
Improvements to DataCap Management
The Filecoin Plus (Fil+) program is dedicated to fostering trust and efficiency within the Filecoin network, and a significant part of this effort involves ensuring the proper allocation and use of DataCap (DC). To enhance transparency, flexibility, and control, we’re introducing a new method for (95 kB)
https://www.fidl.tech/news/improvements-to-datacap-management

blog.allocator.techblog.allocator.tech
Request For Allocators
As we described in a previous post, there are two ways of becoming an Allocator - either you respond to this RFA or propose your own, novel ...
07:24
August
Hi
@mpg
, thank you for the clarification. I’d like to follow up to clarify my situation and next steps.
I have already submitted an application for the experimental pathway metaallocator, as you can see here:
🔗 #12
In your previous feedback there, you mentioned I would need to develop a complete MVP before moving forward.
To fulfill that, I have now completed the front-end and logic part of the allocator, and the only missing piece is the actual allocation of DC via smart contract — which I assumed would be part of the MVP requirement.
07:24
However, from your latest message, I’m a bit confused. If I’m not supposed to use the smart contract to automate DC allocation, then what exactly should I implement in the MVP to qualify for testing?
Could you kindly clarify:
What specifically should be included in the MVP to meet the experimental pathway standard?
Is there a way I can test my logic with real DC, or is there a test setup available?
Should I apply for access to the client contract manually as a regular allocator (even for testing)?
I’d really appreciate your guidance here so I can move forward efficiently — every additional day without clarity increases my development costs significantly.
Thanks again for your time!
11:26
MPG
Hi
@august
, yes you need to develop a full MVP with the smart contract and automation according to your proposal.
You say you implemented all the logic, but I do not see any changes in your repo - there is still one commit from 8 months ago. According to EPMA you need to show "ongoing development".
(edited)
12:17
August
So I just need to create an allocator contract at https://contracts-admin.allocator.tech/allocator and enter a wallet address that has allocator permissions, is that correct?
12:19
yep ,https://www.laughallocator.com/proposals this is the url. I have been developing and testing, but I just didn't upload the code to GitHub. Because I am not sure whether the last step will be successful. Now it seems that the previous content has been completed.
laughallocator.comlaughallocator.com
Laughstorage staking tool
Laughstorage staking tool
13:20
MPG

So I just need to create an allocator contract at https://contracts-admin.allocator.tech/allocator and enter a wallet address that has allocator permissions, is that correct?
No, you can’t do this. The EPMA is already an instance of Allocator.sol. Allocator.sol expects to get a verifreg-based DataCap allowance, and allows authorized addresses to use portions of it.
So if you deploy a new Allocator.sol instance, and get DC via EPMA, it won't work, as it won't have a verifreg-based DC, but a metaallocator-based allowance instead.
13:22
Having discussed with our devs, here is their feedback
So our contract won't have any of the logic they want anyway. And it seems that they already have some kind of a staking contract, so the only thing they're struggling with is DC allocation itself.
What I think would be a good solution for them:
They develop a contract for handling the logic of when and how much to allocate
The contract gets a metaallocator-based DC via EPMA
The contract calls addVerifiedClient on the EPMA Allocator.sol contract whenever it needs to allocate DC to a client ( https://github.com/fidlabs/contract-metaallocator/blob/main/src/Allocator.sol#L99-L107 )

Allocator.sol
/**
* @notice Grant allowance to a client.
* @param clientAddress Filecoin address of the client
* @param amount Amount of datacap to grant
* @dev Emits DatacapAllocated event
Show more
https://github.com/fidlabs/contract-metaallocator|fidlabs/contract-metaallocatorfidlabs/contract-metaallocator | Added by GitHub
13:23
To move forward, we’d like to request access to the smart contract code (or relevant module) that governs current DataCap distribution. Specifically, we’re looking for the Verified Registry Actor implementation or any automation-related components that manage verified client allocations.
You really don't want to interact with verifreg directly, it won't work with metaallocator in the loop.
08:38
August
Hi
@MPG
, thank you for the detailed explanation — I just want to make sure I fully understand the correct approach moving forward.
So to confirm, the right way to implement automated DC allocation is:
I develop a contract that handles the logic of who is eligible for DC and how much they should receive (e.g., based on staking, voting, etc.).
This contract will call addVerifiedClient(address, amount) on the EPMA Allocator.sol contract whenever it needs to allocate DC to a client.
I will need to ensure this contract has the appropriate permissions (i.e., whitelisted or authorized by the EPMA allocator) in order to successfully call that function.
Is this the correct understanding? And if so, who should I reach out to for whitelisting or permission setup?
08:43
If my understanding is not correct, could you let me know what the prerequisites are to integrate and call addVerifiedClient from my contract? What needs to be done in order to enable this?
Thanks again for your guidance — I really appreciate it!
11:56
MPG
Once you have the contract developed (reminder to put things in your repo to show continuous development) we will approve your application to EPMA after reviewing the code
08:26
August
Hey there,
https://github.com/26dos/laughstorage-staking-tool-ui
https://github.com/26dos/staking-tool-contract
URL: https://www.laughallocator.com/proposals
here's the code and URL. Please take a look and let me know if anything needed! Looking forward to your feedback!
laughallocator.comlaughallocator.com
Laughstorage staking tool
Laughstorage staking tool
08:31
Just a note: since we’re still in the testing phase, the URL is not public and is intended for internal testing with your team only. That’s why I haven’t opened an issue on GitHub — I hope you understand.
20:14
MPG
i cannot see the code in the first repo
20:14
image.png

image.png

07:26
August
it works now.
07:10
August
Hey Marta, Looking forward to your feedback.
15:29
MPG
I'm reviewing it, sorry, was very busy over the weekend
16:49
August
Appreciated!
18:42
August
Hey Marta, just checking in to see if there’s any update on the review. Please let me know what should I do now.
We’re hoping to wrap up development soon — the project has already been delayed for quite some time, so your feedback would really help us move forward.
Appreciate your time and support!
09:04
August
Hi! Since I haven’t heard back yet, I was wondering — would it be possible to first add my allocator address to the list so I can test whether the flow works as expected?
We can try with a small amount of DataCap just to verify everything is functioning properly. Let me know if that’s doable — it would really help keep things moving. Thanks again!
17:44
MPG
Hi looking at the code now. Looks good enough, I don't quite see how do you do KYC, from what I can see there is no integration with any library it just takes in photos of IDs but then I dont see analysis of it
06:56
August
Thanks for reviewing the code!
Regarding KYC — we’re currently using a paid verification API from Aliyun, which integrates with Alipay’s identity system (the largest in China). At this stage, it only supports validation of Chinese national ID cards.
Since this is still a testing phase, we’ve kept the scope limited to reduce costs. Once the full flow has been validated and we move into production, we plan to expand support by integrating additional APIs to cover other types of identification globally.

[martapiekarska]

The repositories do not show a good history of development, and this is a bad practice, that generally should be discouraged. Moving forward we expect @26dos to develop all of the code in a transparent and public way. Upon review of the code, I believe that this application does what it promised and is ready for testing. You will be granted 1PiB of DC for testing. Remember, if you run out, there won't be a "Refresh" option - either your experiment works and is ready for security audit and moving into production, or it doesn't in which case you will need to re-apply with explanation of what changed and how.

[martapiekarska]

@26dos please confirm that you are still expecting to receive DC at f410fk3m5nykp5ykl65ytletldbmvflhkta2lbgdhnga

[26dos]

Hi @martapiekarska
Got it — thank you! Going forward, I’ll make sure to keep the GitHub repos up to date in a transparent and timely manner.

Previously we weren’t sure if the flow would work correctly, so we held off on pushing until we could validate the logic. Now that testing is nearly complete, I’m excited to move things forward!

The repositories do not show a good history of development, and this is a bad practice, that generally should be discouraged. Moving forward we expect @26dos to develop all of the code in a transparent and public way. Upon review of the code, I believe that this application does what it promised and is ready for testing. You will be granted 1PiB of DC for testing. Remember, if you run out, there won't be a "Refresh" option - either your experiment works and is ready for security audit and moving into production, or it doesn't in which case you will need to re-apply with explanation of what changed and how.

[26dos]

@26dos please confirm that you are still expecting to receive DC at f410fk3m5nykp5ykl65ytletldbmvflhkta2lbgdhnga

This address is for the staking contract.

I’d like to receive the DC at: f410fipdnqzzlxpzwlxkdo2hjtrcje66dneiyv6nhziq
@martapiekarska

[martapiekarska]

could you please initialise this wallet? also, ideally we would like you to use a Msig so that there is less chance of you loosing access to this wallet. you can create a glif multisig with a couple of wallets controlling the msig. Just don't have both of the wallets on the same HW wallet, cause that won't help with protecting you if in case of a loss;)

[26dos]

@martapiekarska

Hi Marta, thank you again for approving the audit and confirming the address.

Just to confirm the next step:
Our product logic relies on calling the addVerifiedClient(bytes calldata clientAddress, uint256 amount) function from our side, after a client completes the staking process.

In order for this to work, does the address I provided (f410fipdnqzzlxpzwlxkdo2hjtrcje66dneiyv6nhziq) need to be added to the whitelist or authorized within the EPMA Allocator contract to trigger the DataCap allocation? --> this step is equal to I have the right to receive and transfer 1P dc?

Let me know if there’s anything else I should do to enable that flow — appreciate your help!

if it is what I said, then our f4 address is ready.