PIP-48: Native On-Chain Key Delegation (Single-Slot)

[ja7ad]

PIP-48: Native On-Chain Key Delegation (Single-Slot)

[b00f]

@johan256x

Thanks for taking the time to study the code and propose this idea.
Before I go into my comments, I want to restate the core problem and your proposed solution to ensure we’re aligned.

The Problem

Alice has 1 million PAC in her main account. She doesn’t want to use this account for daily small transactions such as buying coffee.
She may also want her secretary to handle small expenses, like grocery shopping without giving access to her main private key or wallet.

Your Solution

Alice can define a single "on-chain" delegation. A delegation acts like a spend-only key.
She can share the delegated secret key with her secretary.
Even if the delegated key is compromised, the main account remains safe.

The overall idea works. However, I have a few concerns.

---

The problem described above is an off-chain problem.
In Pactus, we try to follow an important principle:

Off-chain problems should have off-chain solutions.

This helps us maintain the simplicity of the blockchain while allowing users to build any extra features they need outside the protocol.
Not all users require such a delegation system, but adding it directly into the core increases code complexity for everyone.

Let’s look at the off-chain solutions to the same problem:

1. Alice can send funds to her secretary’s account.

Her secretary provides a PAC address, and Alice transfers the daily or weekly budget to that account.
This approach has the same on-chain cost as sending a delegation transaction.

2. Alice can create two wallets:

• one for large savings
• one for daily transactions

Yes, this means managing two seeds, but even that can be solved.
Using “Deterministic Entropy Keychains” as described in BIP-0085, a user can generate multiple independent wallets from a single seed phrase.
This keeps the security model simple and avoids adding new protocol complexity.

---

I understand that your proposal can help certain users and use cases.
However, in my view, this feature introduces additional complexity into the core codebase without solving a truly on-chain problem.
If an issue can be solved off-chain just as effectively, then it is better to avoid embedding it into the protocol.

This is just my perspective, it doesn’t mean your proposal is invalid or unhelpful.