What is EigenLayer and AVS I keep mentioning. Well let’s dive into this.
EigenLayer is the platform where stakers can provide stake for any infrastructure project, and infrastructure projects can pitch to potential stakers on EigenLayer. The backbone of this platform is “enabling stakers to make credible commitments for different infrastructures”.
Know more about it from this wonderful article: You could’ve invented Eigen Layer
The infrastructure projects mentioned above are AVSs (Actively Validated Services).
AVS are any system that requires its own distributed validation semantics for verification, such as sidechains, data availability layers, new virtual machines, oracle networks, bridges, threshold cryptography schemes, trusted execution environments, or Keeper Networks.
We are creating an keeper network AVS, and then extending its functionality to Tron network, using cross chain bridging.
Hope this clears some of your doubts.
The operators (keepers), who are registered on EigenLayer and our AVS, will have stakers backing them. Our AVS has criteria regarding uptime, task execution success rate, latency to respond to tasks. Wrongful execution of tasks will lead them to be slashed, and eventually being blacklisted if they fail to meet the criteria . If they perform well, they would be rewarded in accordance to EigenLayer rewarding mechanism.
This should make TriggerX more accessible, especially for smaller tasks and your approach to capping fees and batching transactions on Ethereum is a smart strategy to mitigate the impact of high gas costs on users.
How will you handle tasks that fail to execute within the designated fee cap, ensuring users aren’t left with incomplete automation or missed opportunities?
We’ll implement a fallback mechanism where the system attempts to execute the task at regular intervals within the fee cap. If it continues to fail, the user will receive a notification about the issue, allowing them to either adjust the fee cap or manually intervene.
The different automation explained above would come with predefined syntax in our docs for users to follow. If a user wants to automate a call, that contract / function / API would need to be defined as per our defined syntax for arguments and return values.
This is restrictive, and we will have limited functionality due to this, but in future we shall expand the list of options and incorporate more variations and flexibility for users.
The notification system and option for manual intervention are excellent ways to maintain user trust and transparency. And also, your fallback mechanism adds a thoughtful layer of resilience to your platform.
As more users and tasks are added to the network, how will you ensure that the system can handle multiple retries without overloading the network or causing delays?
TriggerX’s approach to bringing advanced automation to the TRON network by extending Keeper Network functionalities is impressive. The way the platform smoothly forwards these capabilities to the TRON blockchain, along with the ability to easily create jobs and manage them through a dashboard, is a standout feature. Great job on delivering such a powerful tool!
TriggerX is a fantastic innovation that brings seamless cross-chain automation to TRON, empowering DeFi users with decentralized task execution! Best of luck to the KPRX Team in making this project a game-changer for the TRON ecosystem!
Welcome to Hackathon Season 7.
TriggerX is truly revolutionizing the TRON ecosystem by bringing advanced automation through its extension of Keeper Network functionalities. The seamless integration of these capabilities for easy job creation and management, makes it an outstanding tool for DeFi users. The innovation behind TriggerX empowers decentralized task execution and cross-chain automation, positioning it as a pioneering force for TRON. Wishing the KPRX Team continued success—keep up the great work and continue pushing the boundaries of what’s possible in DeFi!
Something we’ve carefully considered from the start is scaling for availability and efficiency as the user base grows. We implement mechanisms to manage retries and prevent overloading by optimizing task distribution across keepers. Additionally, we’re setting limits on the number of tasks accepted based on network capacity, ensuring smooth operations without bottlenecks.
As we expand, we’ll continue to adapt and scale to maintain performance and reliability without compromising user experience.
Really appreciate the kind words! We’re committed to pushing boundaries and are excited to bring more innovation to TRON. Thanks for the encouragement!
