PEP-17: Returning a Mistaken DAO Fee, Part 2 Electric Boogaloo

Attributes

Summary

It has come to my attention that a community member made the mistake we all dread making: they swapped the fee and amount values when sending their POKT.

90.91% (10/11ths) of the fee for every transaction goes to the DAO, so we have the means to return the majority of their lost funds, and the block producer has already returned the remaining 9.09% they received.

Motivation

It is possible for the DAO to return the funds, so we should. I see this as an opportunity to set a positive precedent for the UX of our infrastructure service. This type of risk is exactly the kind that discourages mainstream adoption of cryptocurrencies and Web3 infrastructure. So, for the same reason that we are evolving our protocol to offer quality assurances in Pocket 1.0, I believe it may help to offer de-risking assurances like an automatic return of mistaken DAO fees, and I’m now considering a separate proposal to authorize the Foundation to return to sender in scenarios like this.

Rationale

Just to confirm that this happened and that the asking amount is correct…

Here’s the transaction (note the fee amount is 100,000X larger than the send amount):

{
    "hash": "B335342A49C56112DED1E3D5C836219938ADA84C5F1054DA5FA329C22CB9711B",
    "height": 43026,
    "index": 585,
    "proof": {
        "data": null,
        "proof": {
            "aunts": null,
            "index": 0,
            "leaf_hash": null,
            "total": 0
        },
        "root_hash": ""
    },
    "stdTx": {
        "entropy": -5743547524048177000,
        "fee": [
            {
                "amount": "100000000000",
                "denom": "upokt"
            }
        ],
        "memo": "LFG",
        "msg": {
            "type": "pos/Send",
            "value": {
                "amount": "1000000",
                "from_address": "83bf5d0332c46d1a61094106049c671e1b156f49",
                "to_address": "acd5948b382615596dd3f8154a37221c7abcf107"
            }
        },
        "signature": {
            "pub_key": "38883f45d0493f91240d9b6a71e2db4110b6f5719bc931d450f5d72481d6780d",
            "signature": "8d7c8a66fb565306cb28746a9966ab742579de3642af4212fd8e49925dc63e971d4942d2d8593bc1d27a18ac58ae36c4d3ca9abe7a2c691e525fc6b52d354f0e"
        }
    },
    "tx": "2AEKSQoQL3gubm9kZXMuTXNnU2VuZBI1ChSDv10DMsRtGmEJQQYEnGceGxVvSRIUrNWUizgmFVlt0/gVSjciHHq88QcaBzEwMDAwMDASFQoFdXBva3QSDDEwMDAwMDAwMDAwMBpkCiA4iD9F0Ek/kSQNm2px4ttBELb1cZvJMdRQ9dckgdZ4DRJAjXyKZvtWUwbLKHRqmWardCV53jZCr0IS/Y5Jkl3GPpcdSULS2Fk7wdJ6GKxYrjbE08qavnosaR5SX8a1LTVPDiIDTEZHKJTwovTRvrSlsAE=",
    "tx_result": {
        "code": 0,
        "codespace": "",
        "data": null,
        "events": null,
        "info": "",
        "log": "",
        "message_type": "send",
        "recipient": "ACD5948B382615596DD3F8154A37221C7ABCF107",
        "signer": "83BF5D0332C46D1A61094106049C671E1B156F49"
    }
}

Here’s the transaction of the block producer returning their share of the fee:

Note: it should be 9.09% of 99,999 but I’m seeing 9.207%, so the recipient might need to return some to the block producer

{
    "hash": "14212DA27D25CD91B26DB151FD28708F0F11010B30760F8DB8158F84E106E5AA",
    "height": 43056,
    "index": 199,
    "proof": {
        "data": null,
        "proof": {
            "aunts": null,
            "index": 0,
            "leaf_hash": null,
            "total": 0
        },
        "root_hash": ""
    },
    "stdTx": {
        "entropy": 5315877821872569000,
        "fee": [
            {
                "amount": "10000",
                "denom": "upokt"
            }
        ],
        "memo": "send_back",
        "msg": {
            "type": "pos/Send",
            "value": {
                "amount": "9207428146",
                "from_address": "124556107b5cb9e733864ac350fb13d3201a51b8",
                "to_address": "83bf5d0332c46d1a61094106049c671e1b156f49"
            }
        },
        "signature": {
            "pub_key": "7470c8c60718104fc66e90483317cf38312353887fd403405244b43c1d4175a7",
            "signature": "24ffb02117e735a29474f254892501e7b3cfa5b22cddb1bb796b4cd8f19be36f0bb64c11fb325b14f8bb15de25078fd16d7feee505b4ad1bfe44c7b09038df0e"
        }
    },
    "tx": "2QEKTAoQL3gubm9kZXMuTXNnU2VuZBI4ChQSRVYQe1y55zOGSsNQ+xPTIBpRuBIUg79dAzLEbRphCUEGBJxnHhsVb0kaCjkyMDc0MjgxNDYSDgoFdXBva3QSBTEwMDAwGmQKIHRwyMYHGBBPxm6QSDMXzzgxI1OIf9QDQFJEtDwdQXWnEkAk/7AhF+c1opR08lSJJQHns8+lsizdsbt5a0zY8Zvjbwu2TBH7MlsU+LsV3iUHj9Ftf+7lBbStG/5Ex7CQON8OIglzZW5kX2JhY2souvnd0O3W8uJJ",
    "tx_result": {
        "code": 0,
        "codespace": "",
        "data": null,
        "events": null,
        "info": "",
        "log": "",
        "message_type": "send",
        "recipient": "83BF5D0332C46D1A61094106049C671E1B156F49",
        "signer": "124556107B5CB9E733864AC350FB13D3201A51B8"
    }
}

And below we have proof of the DAO’s revenue spiking the block after the fateful transaction was made. The transaction was made at height 43026 and the revenue spikes significantly in block 43027.

Differences in DAO supply:

  • '24-'25: 889,219,818
  • '25-'26: 1,041,133,090
  • '26-'27: 92,074,281,454
  • '27-'28: 1,164,528,636

DAO supply queries:

pocket query account 6386713deb27b609daad5e2e32ee6591753e5f4e 43024
{
    "address": "6386713deb27b609daad5e2e32ee6591753e5f4e",
    "coins": [
        {
            "amount": "56656271094240",
            "denom": "upokt"
        }
    ],
    "name": "dao",
    "permissions": [
        "burner",
        "minter",
        "staking"
    ],
    "public_key": null
}

pocket query account 6386713deb27b609daad5e2e32ee6591753e5f4e 43025
{
    "address": "6386713deb27b609daad5e2e32ee6591753e5f4e",
    "coins": [
        {
            "amount": "56657160314058",
            "denom": "upokt"
        }
    ],
    "name": "dao",
    "permissions": [
        "burner",
        "minter",
        "staking"
    ],
    "public_key": null
}

pocket query account 6386713deb27b609daad5e2e32ee6591753e5f4e 43026
{
    "address": "6386713deb27b609daad5e2e32ee6591753e5f4e",
    "coins": [
        {
            "amount": "56658201447148",
            "denom": "upokt"
        }
    ],
    "name": "dao",
    "permissions": [
        "burner",
        "minter",
        "staking"
    ],
    "public_key": null
}

pocket query account 6386713deb27b609daad5e2e32ee6591753e5f4e 43027
{
    "address": "6386713deb27b609daad5e2e32ee6591753e5f4e",
    "coins": [
        {
            "amount": "56750275728602",
            "denom": "upokt"
        }
    ],
    "name": "dao",
    "permissions": [
        "burner",
        "minter",
        "staking"
    ],
    "public_key": null
}

pocket query account 6386713deb27b609daad5e2e32ee6591753e5f4e 43028
{
    "address": "6386713deb27b609daad5e2e32ee6591753e5f4e",
    "coins": [
        {
            "amount": "56751440257238",
            "denom": "upokt"
        }
    ],
    "name": "dao",
    "permissions": [
        "burner",
        "minter",
        "staking"
    ],
    "public_key": null
}

Dissenting Opinions

Some might argue that this is a precedent we don’t want to set because it won’t be possible to do this every time someone makes this mistake as we scale. However, there are a few reasons I expect this won’t happen often:

  • We are not a transactional cryptocurrency. Transactions will be happening far less than they do in networks like Bitcoin and Ethereum. And when they do happen it will be for larger sums that encourage more caution.
  • Our users are technical professionals who are less likely to make these kinds of errors.
  • This mistake only happens when using the CLI to send transactions. Non-technical users are not going to use the CLI.

To prove this hypothesis, the last known case (PEP-10) was more than 3 months ago.

Even if these mistakes do happen more often than I expect, I believe that:

  • It will be worth the operational cost for the benefit of our UX (see Motivation above)
  • Delegating “return to sender” authority to the Foundation should make it manageable

If we do set this precedent and authorize the Foundation to “return to sender” it will be important to be explicit that this will not cover people for sending POKT the wrong address, for losing their private keys, or for any other mistake that is not specifically putting the send value in the fee field by accident.

Deliverable(s)

If this proposal passes, the Foundation will execute a DAO transfer to return the mistaken fee to the sender.

Authorizing the Foundation to do this in future cases will be a separate proposal.

Copyright

Copyright and related rights waived via CC0.

4 Likes

I am 100% in favor of this. This would also set a good example that the DAO is able help when it can, and should. Bravo :clap:t2:

3 Likes

I hadn’t realized that most of fees go to the DAO. I think that is a brilliant way to safe guard against human errors without any on-chain or ecosystem effects.

I’m for this being the standard process for the very occasional human mishap.

3 Likes

Supported without reservation.

3 Likes

All for it! Thanks for bringing up to our attention.

2 Likes

This proposal is now up for voting

https://gov.pokt.network/#/proposal/0x7053aa5ec13281581a6debcd72722891ba9e7f72af9e9d4f327999f4fb73d050

2 Likes

This proposal has passed! https://cloudflare-ipfs.com/ipfs/QmT8EgWj2GiKpqDrLQsWNH1pac3ud7ZMkgQaDBu9j4Bfqi

3 Likes