<a href="/" class="logo" title="Token Chat is a dedicated space for onchain comments.">TOKEN CHAT SWAP CLUB

This PFP is a collectible which is excluded from official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 21 comments • 5,330 est. $enjoy tips

999 $enjoy

95 $DEGEN

ENJOY $111

enjoyed

So good detective!
100 $Enjoy

1000 $ENJOY

1000 $enjoy

Good art!

enjoy

10 $ENJOY

good

10 $ENJOY

i love this series

Hello

1111 $enjoy

nice
1000 $Enjoy

100 $ENJOY

6 $degen

999 $enojy

nice

nice

See all comments

IMAGE

1024x1024 2.6MB

Degen Detectives (Preview)

Apr 16

This PFP is a collectible which will not be included in official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 46 comments • 39,140 est. $enjoy tips

cool

1000 $enjoy

#WomanLifeFreedom

Hi

3000 $ENJOY
Great job💪

1000 $enjoy

222 $Enjoy

Nice
500 $DEGEN

Degen Detectives !!

1

so good 100 $Enjoy

!Imagine

good~~ $degen

100 $ENJOY

lets go!

degen

DEGEN! 100 $Enjoy

Higher

1 $degen

degen

Nice :)

NICE

degen

Rare Degen Detectives

100 $enjoy

100 $DEGEN

999 $ENJOY

777 $higher

amazing

mint

500 $enjoy

629 $ENJOY

1000 $enjoy
1000 $imagine basedsui.eth

언제까지 내냐 77 $enjoy

Imagine

10000 $enjoy

support

💎 Follow/MINT Back and Bonus 💎

Love 🩷🩷🩷 $IMAGINE $ONCHAIN and $ENJOY this beautiful time $DEGEN

Finally get one!

2

Lovely

IMAGINE

101 $ENJOY

112 $Enjoy

20000 $Enjoy for ramiata.eth

Apr 16

0xd9c7 2x

No1 SUI 100 $enjoy $higher $imagine

See all comments

IMAGE

1024x1024 2.7MB

Degen Detectives (Preview)

Apr 15

0xe7cdbead429e6acb46da2343a507ec5747147844 11x

This PFP is a collectible which will not be included in official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 92 comments • 90,297 est. $enjoy tips

100 $ENjoy

Tks

11 $ENJOY

66666 $ENJOY

333 $Enjoy

degen

degen

nice!

gogogo!!!

LFG!

$degen

1111 $Enjoy

$degen

Degen Detectives

detctives

555 $Enjoy

100 $DEGEN

22 $DEGEN

LFG man

degen

5555 $enjoy

lfg

degen

$DEGEN

$degen Let's go!!!

$degen

Good : )

2 $degen

good 500 $enjoy

$enjoy 10

$degen good

lfg!!

wow awesome!!

77 $ENJOY

$DEGEN

1 $enjoy

77 $ENJOY

great

7

111 $enjoy

Good!

ayo

100 $enjoy

studying

enjoy $DEGEN

ENJOY DEGEN

20 $degen
Purple is loyal

Lets degen

zora

hi

Enjoy

1 $ENJOY

Degen

Wow

10 $ enjoy

1 $enjoy

11 $DEGEN

Good

Degen Detectives

Degen Detectives

Degen Detectives

Degen Detectives

Degen Detectives

Gazua!!

degen

300 $ENJOY

degen

zora

letsgo degen

mong

asasd

good

enjoy degen

degen

good

degen

1000 $enjoy

ㅎㅎ

100 $ENJOY

77 $enjoy

100 $ENJOY

lfg

good sui 100 $enjoy $higher $imagine

enjoy degen

1000 $Enjoy

Enjoy your day

DEGEN

1111 $Enjoy

1000 $ENJOY
great!

10000 $ENJOY

310 $ENJOY

good

See all comments

IMAGE

1024x1024 2.7MB

Degen Detectives (Preview)

Apr 15

This PFP is a collectible which will not be included in official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 34 comments • 715,829 est. $enjoy tips

7000 $ENJOY

1

2 so 2

sui

degen

good

100 $degen

500 $ENJOY

5111 $Enjoy

376 $ENJOY

1000 $ENJOY

100 $enjoy

1111 $enjoy

11 $enjoy

like

3

25000 $enjoy

111 $ENJOY

1000 $ENJOY

BEAUTIFUL WORK! 666666 $enjoy

1 $degen

100 $ENJOY

SUI PROJECT

Smiley :)

1300 $ENJOY

11 $degen

$1000 $DEGEN

5555 $ENJOY

degen

Mintef

10

thx good

777 $ENJOY

111 $enjoy

See all comments

IMAGE

1024x1024 2.6MB

Degen Detectives (Preview)

Apr 14

This PFP is a collectible which will not be included in official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 39 comments • 23,944 est. $enjoy tips

detectives

222 $DEGEN

222 $ENJOY

111 $enjoy

yay

101 $ENJOY

100 $enjoy

gow

NICE

222 $DEGEN

10000 $ENJOY

Unique Rare Degen Detectives

100 $ENJOY

200 $DEGEN

degen

2000 $ENJOY

good nft

1 $ENJOY

degen

degen

777 $Enjoy

Your art is too compelling to miss out on. 

1000 $enjoy

111 $Enjoy

1$degen

thx $higher $imagine $enjoy

Apr 14

cuttlas 11x

I like your art and the culture in it
2222 $ENJOY

sui

$degen

222 $ENJOY

1000 $Enjoy
Thanks

2

:))

1

degen

yes

Lfg!

5900 $ENJOY

nice

77 $enjoy

See all comments

IMAGE

1024x1024 2.7MB

Degen Detectives (Preview)

Apr 14

0xe7cdbead429e6acb46da2343a507ec5747147844 3x

This PFP is a collectible which will not be included in official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 47 comments • 24,510 est. $enjoy tips

10 $degen

hi 6 $DEGEN

Degen

10000 $ENJOY

1000 $enjoy

2000 $enjoy

Avi

degen

lfg

Pn

lfg

degen

$DEGEN

hi

pretty girl

10000 $ENJOY

degen

FIghting $Degen

1 $degen

degen

aa

$DEGEN

1 $enjoy

gogogo

degen

LFG!!

gmn

100 $enjoy

Degen! FIghting

500 $ENJOY

11 $enjoy

fgdffdgd

ㅎㅎ

1 $DEGEN 1 $ZORA

777 $enjoy

gg

10 $ENJOY

great!

degen

11 $enjoy

Degen

Degen Detectives (Preview)

lfg

100 $ENJOY

gogogo

degen

Good

See all comments

IMAGE

1024x1024 2.6MB

Degen Detectives (Preview)

Apr 13

This PFP is a collectible which will not be included in official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 131 comments • 9,223,372,036,854,790,144 est. $enjoy tips

Nice hat

Pn

1$ degen

10 $ENJOY

good project!

AWESOME!!!

hello

33 $DEGEN

$degen

Mintes

hello

mihorin

5 $DEGEN

100 $degen

go

1 $DEGEN

$DEGEN

3 $degen

$DEGEN

Degen Detectives

hh

Nice!

4

DEGEN

Enjoy

degen

Nice!

777

degen

hihi

lfg~!

good

11 $degen

100 $ENJOY

degen

good

rwrw

ENJOY

115792089237316195423570985008687907853269984665640564039457584007913129639935 $ENJOY 115792089237316195423570985008687907853269984665640564039457584007913129639935 $DEGEN

DEGEN

me toot

go

하이

$degen

degen

3132

ENJOY

100 $ENJOY

100 $DEGEN

$degen

degen

100 $enjoy

sseexx

100 $ENJOY

1000$enjoy

1

mihorin

lfg

LFG!!

nice

100 $enjoy

wow

100 $ENJOY

LFG!!

100 $DEGEN

1 $degen

100 $ENJOY

100 $ENJOY

200 $enjoy

1$ DEGEN

1 $ENJOY ! DD!!

$degen

Hhjg

1$degen

zora

111 $enjoy

100 $ENJOY

100 $ENJOY

oodgoog

gg

100 $enjoy

999 $Enjoy

100 $enjoy

5

Degennn

777 $enjoy

1 $enjoy

1 $ENJOY

100 $enjoy

$DEGEN

1 $degen

enjoy~

100 $ENJOy

1 $ENJOY

100 $ENJOY

degen

mint

degen

lfg

bligoon

100 $ENJOY

1 $DEGEN

77 $enjoy

10000 $ENJOY

LFG

100 $ENJOY

degen

let go

hi

Hhj

Degen

100 $Enjoy

100 $enjoy

7 $ENJOY

mong

5000 $ENJOY

degen

WHAT

LFG

degen

good

10 $enjoy

degen!!! 777

nice

Who sould $DEGEN ?

lfg

Unique Rare Degen Detectives

77 $enjoy

111 $enjoy

33

100 $ENJOY

See all comments

IMAGE

1024x1024 2.7MB

Degen Detectives (Preview)

Apr 13

This PFP is a collectible which will not be included in official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 146 comments • 40,643 est. $enjoy tips

1 $degen

good

3 $DEGEN

100 $ENJOY

zora

sex

pew

100 $ENJOY

lets go 100$enjoy !

Degen

hiji

degen

Degennn

lfg

100 $enjoy

11 $degen

100 $DEGEN

1 $enjoy

good

degen

하이

1 $ENJOY ! DEGEN DE

100 $ENJOY

1$degen

enjoy~

1 $ENJOY

$ENJOY!

100 $ENJOY

100 $DEGEN

100 $ENJOY

wow

mint

5

degen!!! 777

100 $ENJOY

111 $enjoy

100 $ENJOY

11

10 $enjoy

gogogo

1000$enjoy

LFG

bligoon

3 $degen

1 $DEGEN

--- eip: 3074 title: AUTH and AUTHCALL opcodes description: Allow externally owned accounts to delegate control to a contract. author: Sam Wilson (@SamWilsn), Ansgar Dietrichs (@adietrichs), Matt Garnett (@lightclient), Micah Zoltu (@micahzoltu) discussions-to: ethereum-magicians.org/t/eip-3074-sponsored-transaction-precompile/4880 status: Review type: Standards Track category: Core created: 2020-10-15 requires: 155 --- ## Abstract This EIP introduces two EVM instructions `AUTH` and `AUTHCALL`. The first sets a context variable `authorized` based on an ECDSA signature. The second sends a call as the `authorized` account. This essentially delegates control of the externally owned account (EOA) to a smart contract. ## Motivation Adding more functionality to EOAs has been a long-standing feature request. The requests have spanned from implementing batching capabilities, allowing for gas sponsoring, expirations, scripting, and beyond. These changes often mean increased complexity and rigidity of the protocol. In some cases, it also means increased attack surfaces. This EIP takes a different approach. Instead of enshrining these capabilities in the protocol as transaction validity requirements, it allows users to *delegate* control of their EOA to a contract. This gives developers a flexible framework for developing novel transaction schemes for EOAs. A motivating use case of this EIP is that it allows any EOA to act like a smart contract wallet *without* deploying a contract. Although this EIP provides great benefit to individual users, the leading motivation for this EIP is "sponsored transactions". This is where the fee for a transaction is provided by a different account than the one that originates the call. With the extraordinary growth of tokens on Ethereum, it has become common for EOAs to hold valuable assets without holding any ether at all. Today, these assets must be converted to ether before they can be used to pay gas fees. However, without ether to pay for the conversion, it's impossible to convert them. Sponsored transactions break the circular dependency. ## Specification ### Conventions - **`top - N`** - the `N`th most recently pushed value on the EVM stack, where `top - 0` is the most recent. - **`||`** - byte concatenation operator. - **invalid execution** - execution that is invalid and must exit the current execution frame immediately, consuming all remaining gas (in the same way as a stack underflow or invalid jump). ### Constants | Constant | Value | | ---------------- | ------ | | `MAGIC` | `0x04` | `MAGIC` is used for [EIP-3074](./eip-3074.md) signatures to prevent signature collisions with other signing formats. ### Context Variables | Variable | Type | Initial Value | | ------------------- | --------- |:------------- | | `authorized` | `address` | unset | The context variable `authorized` shall indicate the active account for `AUTHCALL` instructions in the current frame of execution. If set, `authorized` shall only contain an account which has given the contract authorization to act on its behalf. An unset value shall indicate that no such account is set and that there is not yet an active account for `AUTHCALL` instructions in the current frame of execution. The variable has the same scope as the program counter -- `authorized` persists throughout a single frame of execution of the contract, but is not passed through any calls (including `DELEGATECALL`). If the same contract is being executed in separate execution frames (ex. a `CALL` to self), both frames shall have independent values for `authorized`. Initially in each frame of execution, `authorized` is always unset, even if a previous execution frame for the same contract has a value. ### `AUTH` (`0xf6`) A new opcode `AUTH` shall be created at `0xf6`. It shall take three stack element inputs (the last two describing a memory range), and it shall return one stack element. #### Input ##### Stack | Stack | Value | | ---------- | ------------ | | `top - 0` | `authority` | | `top - 1` | `offset` | | `top - 2` | `length` | ##### Memory The final two stack arguments (`offset` and `length`) describe a range of memory. The format of the contents of that range is: - `memory[offset : offset+1 ]` - `yParity` - `memory[offset+1 : offset+33]` - `r` - `memory[offset+33 : offset+65]` - `s` - `memory[offset+65 : offset+97]` - `commit` #### Output ##### Stack | Stack | Value | | ---------- | -------------| | `top - 0` | `success` | ##### Memory Memory is not modified by this instruction. #### Behavior If `length` is greater than 97, the extra bytes are ignored for signature verification (they still incur a gas cost as defined later). Bytes outside the range (in the event `length` is less than 97) are treated as if they had been zeroes. `authority` is the address of the account which generated the signature. The arguments (`yParity`, `r`, `s`) are interpreted as an ECDSA signature on the secp256k1 curve over the message `keccak256(MAGIC || chainId || nonce || invokerAddress || commit)`, where: - `chainId` is the current chain's [EIP-155](./eip-155.md) unique identifier padded to 32 bytes. - `nonce` is the signer's current nonce, left-padded to 32 bytes. Any other value is considered invalid. - `invokerAddress` is the address of the contract executing `AUTH` (or the active state address in the context of `CALLCODE` or `DELEGATECALL`), left-padded with zeroes to a total of 32 bytes (ex. `0x000000000000000000000000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA`). - `commit`, one of the arguments passed into `AUTH`, is a 32-byte value that can be used to commit to specific additional validity conditions in the invoker's pre-processing logic. Signature validity and signer recovery are handled analogously to transaction signatures, including the stricter `s` range for preventing ECDSA malleability. Note that `yParity` is expected to be `0` or `1`. If the signature is valid and the signer address is equal to `authority`, the context variable `authorized` is set to the `authority`. In particular, this is also true if `authority == tx.origin`, which used to be handled separately in earlier versions of this EIP (see Security Considerations). If the signature is instead invalid or the signer address does not equal `authority`, `authorized` is reset to an unset value. `AUTH` returns `1` if `authorized` is set, or `0` otherwise. #### Gas Cost The gas cost for `AUTH` is equal to the sum of: - fixed fee `3100`. - memory expansion gas cost (`auth_memory_expansion_fee`). - `100` if `authority` is warm, `2600` if it is cold (per [EIP-2929](./eip-2929.md)). The fixed fee is equal to the cost for the `ecrecover` precompile, plus a bit extra to cover a keccak256 hash and some additional logic. The memory expansion gas cost (`auth_memory_expansion_fee`) shall be calculated in the same way as `RETURN`, where memory is expanded if the specified range is outside the current allocation. ### `AUTHCALL` (`0xf7`) A new opcode `AUTHCALL` shall be created at `0xf7`. It shall take seven stack elements and return one stack element. It matches the behavior of the existing `CALL` (`0xF1`) instruction, except where noted below. #### Input | Stack | Value | | --------- | ------------ | | `top - 0` | `gas` | | `top - 1` | `addr` | | `top - 2` | `value` | | `top - 3` | `argsOffset` | | `top - 4` | `argsLength` | | `top - 5` | `retOffset` | | `top - 6` | `retLength` | #### Output | Stack | Value | | ---------- | --------- | | `top - 0` | `success` | #### Behavior `AUTHCALL` is interpreted the same as `CALL`, except for (note: this list is also the order of precedence for the logical checks): - If `authorized` is unset, execution is invalid (as defined above). Otherwise, the caller address for the call is set to `authorized`. - The gas cost, including how much gas is available for the subcall, is specified in the Gas Cost section. - If the `gas` operand is equal to `0`, the instruction will send all available gas as per [EIP-150](./eip-150). - If the gas available for the subcall would be less than `gas`, execution is invalid. - There is no gas stipend, even for non-zero `value`. - `value` is deducted from the balance of `authorized`. If `value` is higher than the balance of `authorized`, execution is invalid. `AUTHCALL` must increase the call depth by one. `AUTHCALL` must not increase the call depth by two as it would if it first called into the authorized account and then into the target. The return data area accessed with `RETURNDATASIZE` (`0x3d`) and `RETURNDATACOPY` (`0x3e`) must be set in the same way as the `CALL` instruction. Importantly, `AUTHCALL` does not reset `authorized`, but leaves it unchanged. #### Gas Cost The gas cost for `AUTHCALL` shall be the **sum** of: - static gas cost (`warm_storage_read`) - memory expansion gas cost (`memory_expansion_fee`) - dynamic gas cost (`dynamic_gas`) - gas available for execution in the subcall (`subcall_gas`) The memory expansion gas cost (`memory_expansion_fee`) shall be calculated in the same way as `CALL`. The dynamic gas portion (`dynamic_gas`), and the gas available for execution in the subcall (`subcall_gas`) shall be calculated as: ``` dynamic_gas = 0 if addr not in accessed_addresses: dynamic_gas += 2500 # cold_account_access - warm_storage_read if value > 0: dynamic_gas += 6700 # NB: Not 9000, like in `CALL` if is_empty(addr): dynamic_gas += 25000 remaining_gas = available_gas - dynamic_gas all_but_one_64th = remaining_gas - (remaining_gas // 64) if gas == 0: subcall_gas = all_but_one_64th elif all_but_one_64th < gas: raise # Execution is invalid. else: subcall_gas = gas ``` As with `CALL`, the full gas cost is charged immediately, independently of actually executing the call. ## Rationale ### Signature in Memory The signature format (`yParity`, `r`, and `s`) is fixed, so it might seem curious that `auth` accepts a dynamic memory range. The signature is placed in memory so that `auth` can be upgraded in the future to work with contract accounts (which might use non-ECDSA signatures) and not just EOAs. ### Signing Address `auth` Argument Including `authority` (the signing address) as an argument to `auth` allows future upgrades to the instruction to work with contract accounts, and not just EOAs. If `authority` were not included and multiple signature schemes allowed, it would not be possible to compute the authorizing account's address from just the signature alone. ### Reserving One Sixty-Fourth of Available Gas `AUTHCALL` will not pass more than 63/64th of the available gas for the reasons enumerated in [EIP-150](./eip-150.md). ### Throwing for Unset `authorized` During `AUTHCALL` A well-behaved contract should never reach an `AUTHCALL` without having successfully set `authorized` beforehand. The safest behavior, therefore, is to exit the current frame of execution immediately. This is especially important in the context of transaction sponsoring / relaying, which is expected to be one of the main use cases for this EIP. In a sponsored transaction, the inability to distinguish between a sponsee-attributable fault (like a failing sub-call) and a sponsor-attributable fault (like a failing `AUTH`) is especially dangerous and should be prevented because it charges unfair fees to the sponsee. ### Another Sponsored Transaction EIP There are two general approaches to separating the "fee payer" from the "action originator". The first is introducing a new transaction type. This requires significant changes to clients to support and is generally less upgradeable than other solutions (e.g. this EIP). This approach is also not immediately compatible with account abstraction (AA). These proposals require a *signed* transaction from the sponsor's account, which is not possible from an AA contract, because it has no private key to sign with. The main advantage of new transaction types is that the validity requirements are enforced by the protocol, therefore invalid transactions do not pollute block space. The other main approach is to introduce a new mechanism in the EVM to masquerade as other accounts. This EIP introduces `AUTH` and `AUTHCALL` to make calls as EOAs. There are many different permutations of this mechanism. An alternative mechanism would be to add an opcode that can make arbitrary calls based on a similar address creation scheme as `CREATE2`. Although this mechanism would not benefit users today, it would immediately allow for those accounts to send and receive ether -- making it feel like a more first-class primitive. Besides better compatibility with AA, introducing a new mechanism into the EVM is a much less intrusive change than a new transaction type. This approach requires no changes in existing wallets, and little change in other tooling. `AUTHCALL`'s single deviation from `CALL` is to set `CALLER`. It implements the minimal functionality to enable sender abstraction for sponsored transactions. This single mindedness makes `AUTHCALL` significantly more composable with existing Ethereum features. More logic can be implemented around the `AUTHCALL` instruction, giving more control to invokers and sponsors without sacrificing security or user experience for sponsees. ### What to Sign? As originally written, this proposal specified a precompile with storage to track nonces. Since a precompile with storage is unprecedented, a revision moved replay protection into the invoker contract, necessitating a certain level of user trust in the invoker. Expanding on this idea of trusted invokers, the other signed fields were eventually eliminated, one by one, until only `invoker` and `commit` remained. The `invoker` binds a particular signed message to a single invoker. If invoker was not part of the message, any invoker could reuse the signature to completely compromise the EOA. This allows users to trust that their message will be validated as they expect, particularly the values committed to in `commit`. ### Understanding `commit` Earlier iterations of this EIP included mechanisms for replay protection, and also signed over value, gas, and other arguments to `AUTHCALL`. After further investigation, we revised this EIP to its current state: explicitly delegate these responsibilities to the invoker contract. A user will specifically interact with an invoker they trust. Because they trust this contract to execute faithfully, they will "commit" to certain properties of a call they would like to make by computing a hash of the call values. They can be certain that the invoker will only allow they call to proceed if it is able to verify the values committed to (e.g. a nonce to protect against replay attacks). This certainty arises from the `commit` value that is signed over by the user. This is the hash of values which the invoker will validate. A safe invoker should accept the values from the user and compute the commit hash itself. This ensures that invoker operated on the same input that user authorized. ![auth message format](../assets/eip-3074/auth-msg.png) Using `commit` as a hash of values allows for invokers to implement arbitrary constraints. For example, they could allow accounts to have `N` parallel nonces. Or, they could allow a user to commit to multiple calls with a single signature. This would allow multi-tx flows, such as [ERC-20](./eip-20.md) `approve`-`transfer` actions, to be condensed into a single transaction with a single signature verification. A commitment to multiple calls would look something like the diagram below. ![multi-call auth message](../assets/eip-3074/auth-msg-multi-call.png) ### Invoker Contracts The invoker contract is a trustless intermediary between the sponsor and sponsee. A sponsee signs over `invoker` to require they transaction to be processed only by a contract they trust. This allows them to interact with sponsors without needing to trust them. Choosing an invoker is similar to choosing a smart contract wallet implementation. It's important to choose one that has been thoroughly reviewed, tested, and accepted by the community as secure. We expect a few invoker designs to be utilized by most major transaction relay providers, with a few outliers that offer more novel mechanisms. An important note is that invoker contracts **MUST NOT** be upgradeable. If an invoker can be redeployed to the same address with different code, it would be possible to redeploy the invoker with code that does not properly verify `commit` and any account that signed a message over that invoker would be compromised. Although this sounds scary, it is no different than using a smart contract wallet via `DELEGATECALL`. If the wallet is redeployed with different logic, all wallets using its code could be compromised. ### On Call Depth The EVM limits the maximum number of nested calls, and naively allowing a sponsor to manipulate the call depth before reaching the invoker would introduce a griefing attack against the sponsee. That said, with the 63/64th gas rule, and the cost of `AUTHCALL`, the stack is effectively limited to a much smaller depth than the hard maximum by the `gas` parameter. It is, therefore, sufficient for the invoker to guarantee a minimum amount of gas, because there is no way to reach the hard maximum call depth with any reasonable (i.e. less than billions) amount of gas. ### Source of `value` In previous iterations of this EIP, it was thought that deducting value from an EOA mid-execution was problematic. This was due to an invariant of pending transactions which allows tx pools to statically determine the validity of a given transaction. However, after further investigation we found that breaking the invariant is safe. This is mostly due to the fact that the worst case is similar in both instances. Currently an attacker can queue many transactions in the tx pool, across many accounts, and invalidate them all at once with a block where each of the queued accounts send a tx moving their entire balance. This attack will become easier and cheaper after this EIP, because it will no longer require direct access to the block builder and will not cost a full 21000 gas to originate each tx. However, the attack does not have a substantial impact on the network, so reducing the difficulty and cost is not of concern. ### Allowing `tx.origin` as Signer Allowing `authorized` to equal `tx.origin` enables simple transaction batching, where the sender of the outer transaction would be the signing account. The ERC-20 approve-then-transfer pattern, which currently requires two separate transactions, could be completed in a single transaction with this proposal. `AUTH` allows for signatures to be signed by `tx.origin`. For any such signatures, subsequent `AUTHCALL`s have `msg.sender == tx.origin` in their first layer of execution. Without EIP-3074, this situation can only ever arise in the topmost execution layer of a transaction. This EIP breaks that invariant and so affects smart contracts containing `require(msg.sender == tx.origin)` checks. This check can be used for at least three purposes: 1. Ensuring that `msg.sender` is an EOA (given that `tx.origin` always has to be an EOA). This invariant does not depend on the execution layer depth and, therefore, is not affected. 2. Protecting against atomic sandwich attacks like flash loans, that rely on the ability to modify state before and after the execution of the target contract as part of the same atomic transaction. This protection would be broken by this EIP. However, relying on `tx.origin` in this way is considered bad practice, and can already be circumvented by miners conditionally including transactions in a block. 3. Preventing reentrancy. Examples of (1) and (2) can be found in contracts deployed on Ethereum mainnet, with (1) being more common (and unaffected by this proposal.) On the other hand, use case (3) is more severely affected by this proposal, but the authors of this EIP did not find any examples of this form of reentrancy protection, though the search was non-exhaustive. This distribution of occurrences—many (1), some (2), and no (3)—is exactly what the authors of this EIP expect, because: - Determining if `msg.sender` is an EOA without `tx.origin` is difficult (if not impossible.) - The only execution context which is safe from atomic sandwich attacks is the topmost context, and `tx.origin == msg.sender` is the only way to detect that context. - In contrast, there are many direct and flexible ways of preventing reentrancy (ex. using a storage variable.) Since `msg.sender == tx.origin` is only true in the topmost context, it would make an obscure tool for preventing reentrancy, rather than other more common approaches. There are other approaches to mitigate this restriction which do not break the invariant: - Set `tx.origin` to a constant `ENTRY_POINT` address for `AUTHCALL`s. - Set `tx.origin` to the invoker address for `AUTHCALL`s. - Set `tx.origin` to a special address derived from any of the sender, invoker, and/or signer addresses. - Disallow `authorized == tx.origin`. This would make the simple batching use cases impossible, but could be relaxed in the future. ### `AUTHCALL` cheaper than `CALL` when sending value Sending non-zero value with `CALL` increases its cost by 9,000. Of that, 6,700 covers the increased overhead of the balance transfer and 2,300 is used as a stipend into the subcall to seed its gas counter. `AUTHCALL` does not provide a stipend and thus only charges the base 6,700. ### In-Protocol Revocation This EIP has gone [back and forth](#what-to-sign) on how to deal with `AUTH` message revocation. Without revocation, this EIP is a supremely powerful and flexible primitive for developers. However, it does have risk for users who use insecure and/or actively malicious invokers. Much of the risk is due to the new ability for users to batch many operations in a single transaction. It becomes easier for an account to be drained. This is a risk that will continue to grow, regardless of the adoption of this EIP, due to overwhelming desire for the feature and attempts to support it at the protocol level and at the app level. A new class of risk is introduced for insecure and buggy invokers. If an invoker has implemented replay protection, as per the authors' recommendation, this should substantially contain the blast radius. However, if the bug allows an adversary to circumvent the replay protection mechanism, it may give them full access to any EOA which has interacted with the vulnerable invoker. Although this is a truly catastrophic event which is not expected to be possible via reputable wallets, it is a serious consideration. Without in-protocol revocation, users have no way to remove their account from the vulnerable invoker. For this reason, `AUTH` requires the `nonce` in the message to be equal to the signer's current nonce. This way, a single tx from the EOA will cause the nonce to increase, invalidating all outstanding authorizations. ## Backwards Compatibility Although this EIP poses no issues for backwards compatibility, there are concerns that it limits future changes to accounts by further enshrining ECDSA signatures. For example, it might be desirable to eradicate the concept of EOAs altogether, and replace them with smart contract wallets that emulate the same behavior. This is fully compatible with the EIP as written, however, it gets tricky if users can then elect to "upgrade" their smart contract wallets to use other methods of authentication -- e.g. convert into a multi-sig. Without any changes, `AUTH` would not respect this new logic and continue allowing the old private key to perform actions on behalf of the account. A solution to this would be at the same time that EOAs are removed, to modify the logic of `AUTH` to actually call into the account with some standard message and allow the account to determine if the signature / witness is valid. Further research should be done to understand how invokers would need to change in this situation and how best to write them in a future-compatible manner. ## Security Considerations ### Secure Invokers The following is a non-exhaustive list of checks/pitfalls/conditions that invokers *should* be wary of: - Replay protection (ex. a nonce) should be implemented by the invoker, and included in `commit`. Without it, a malicious actor can reuse a signature, repeating its effects. - `value` should be included in `commit`. Without it, a malicious sponsor could cause unexpected effects in the callee. - `gas` should be included in `commit`. Without it, a malicious sponsor could cause the callee to run out of gas and fail, griefing the sponsee. - `addr` and `calldata` should be included in `commit`. Without them, a malicious actor may call arbitrary functions in arbitrary contracts. A poorly implemented invoker can *allow a malicious actor to take near complete control over a signer's EOA*. ### Allowing `tx.origin` as Signer Allowing `authorized` to equal `tx.origin` has the possibility to: - Break atomic sandwich protections which rely on `tx.origin`; - Break reentrancy guards of the style `require(tx.origin == msg.sender)`. The authors of this EIP believe the risks of allowing `authorized` to equal `tx.origin` are acceptable for the reasons outlined in the Rationale section. ### Sponsored Transaction Relayers It is possible for the `authorized` account to cause sponsored transaction relayers to spend gas without being reimbursed by either invalidating the authorization (i.e. increasing the account's nonce) or by sweeping the relevant assets out of the account. Relayers should be designed with these cases in mind, possibly by requiring a bond to be deposited or by implementing a reputation system. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).

100 $ENJOY100 $ENJOY

good

g

100 $ENJOY

1$ Degen forever

enjoy!

Degen Detectives gogo!!!!!!

5000 $ENJOY

10 $enjoy

999 $Enjoy

100 $ENJOY

10 $ENJOY

10000 $ENJOY

1 $enjoy 1 $imagine

$DEGEN

555 $DEGEN

Degen Detectives

degen go!

degen

degen

100 $ENJOY

100 $ENJOY

good project!

100 $ENJOY

10000 $ENJOY

very nice

degen!

choice

100 $enjoy

degen!!!

50

GO GO

lfg good

111 $degen

1 $ENJOY

100 $ENJOY

777 $enjoy

1 $enjoy

dd

Degen Detectives (Preview)

Lll

1$degen

111 $enjoy

1 $degen

100 $ENJOY

gogogoog

100 $ENJOY

100 $Enjoy

100 $Enjoy

God

777 $enjoy

LFG

hi

degen

LFG!

lfg

1 $enjoy

Imagine

3

Go

degen detectives

LFG!!!

degen

100 $ENJOY

good choice

10 $degen

100 $enjoy

100 $ENJOY

gogo

333

degen gazuaaaa

1

degen

dd

d

lfg

1 $degen

7

777 $enjoy

LFG!!!

degen~

degen

100 $enjoy

GO

helo

LFG!!!

hhh

fsafsasfa

Imagine

!imadgine

33 $enjoy

21

13

4400 $ENJOY

Gm

Nice

11

100 $ENJOY

122 $enjoy

5000 $ENJOY

See all comments

IMAGE

1024x1024 2.6MB

Degen Detectives

This PFP is a collectible which will not be included in official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 29 comments • 21,280 est. $enjoy tips

Thanks

DEGEN!

777 $Enjoy

Cool. 1,000 $enjoy

50 $ENJOY

7

777 $Enjoy 77 $Imagine

ihour 3x

💙 Detectives for base degens 💙

$ENJOY

$ENJOY

4

7

DegenWorldBuildersAreEveryWhere

0xd9c7 2x

today is good 100 $enjoy $higher $imagine

1500 $enjoy

im earlyyyy

Thirdweb

222 $Enjoy

1 $degen

let's go detective

Thanks Zora

1111 $Enjoy

2200 $ENJOY

tnx

1000 $enjoy

111 $enjoy

0xpayam.payammahmoodi 3x

2321 $Enjoy

111 $enjoy

10000 $ENJOY

See all comments

IMAGE

1024x1024 2.6MB

Degen Detectives

This PFP is a collectible which is excluded from official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 13 comments • 10,554 est. $enjoy tips

great

10 $Enjoy 10 $Imagine to obbyrobs

333 $ENJOY

🍖 x 100

Hey,what’s up?

good d 100 $enjoy $higher $imagine

3

imagine

imagine

111 $enjoy

Unique Rare Degen Detectives

1

10000 $ENJOY

See all comments

IMAGE

1024x1024 2.6MB

Degen Detectives

This PFP is a collectible which is excluded from official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 17 comments • 11,765 est. $enjoy tips

10

great colors

50

lovely

100$ Enjoy good art

100

100 $enjoy

10

You are caught!

Nice

100 $ENJOY

5000 $enjoy

333 $enjoy

10 $Enjoy

111 $enjoy

5000 $enjoy

1111 $enjoy

See all comments

IMAGE

1024x1024 2.2MB

Degen Detectives

This PFP is a collectible which is excluded from official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 17 comments • 62,555 est. $enjoy tips

100 $degen

5

5000 $enjoy

Follow @chainsmokers on warp

1111 $ENJOY

333 $enjoy

true detective

7

lovely detective

great

10 $IMAGINE to sui

2

sui

Nice

50000 $ENJOY

1111 $enjoy

5000 $ENJOY

See all comments

IMAGE

1024x1024 2.8MB

Degen Detectives

This PFP is a collectible which is excluded from official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 46 comments • 7,631 est. $enjoy tips

1 $degen

god

999 $Enjoy

1degen

300 $enjoy

1000 $enjoy

DEGEN

100 $enjoy

??

letgo

ggogo

1000 $ENJOY

11 $DEGEN

111 $enjoy

1000 $ENJOY

very nice

100 $ENJOY

lfg

1 $degen

1000 $enjoy

11 $degen

degen!

1 $Enjoy

777 $enjoy

LFG

111 $

100 $Enjoy

100 $Enjoy

degen

Degen

$degen 1

lfg

100enjoy$

1

100 $DEGEN

degen

11

degen

11 $Degen

degen!

33 $enjoy

10 $Enjoy

Good

1000 $enjoy

6000 $DEGEN

See all comments

IMAGE

1024x1024 2.8MB

Degen Detectives

This PFP is a collectible which is excluded from official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 47 comments • 16,098 est. $enjoy tips

1000 $Enjoy

good

2323

degen

Goo

100 $ENJOY

1000 $ENJOY

LFG

degen lfg

degen

50

100 $enjoy

Goo

Enjoy

111 $enjoy

degen

degen

Degen

degen

good

1

lfg

degen

degen 1$

10 $ENJOY

300 $Enjoy

10 $DEGEN

1000 $ENJOY

degen

77 $enjoy

lfg

300 $enjoy

1

good

degen!

11 $degen

gg

$enjoy

degen

??

1000 $enjoy

50

100 $ENJOY

5000 $enjoy

Minted

1000 $Enjoy

5000 $ENJOY

See all comments

IMAGE

1024x1024 2.6MB

Degen Detectives

This PFP is just a collectible which is excluded from official Degen Detectives Collection. Don't expect any monetary value.

📶 62 comments • 13,337 est. $enjoy tips

degen

100 $ENJOY

good

$DEGEN

lfg

NICE

Degen

11

1500 $ENJOY

hello!!

good

LFG

Degen!

bligoon

100

degen

100 $enjoy

1 $ENJOY

777 $enjoy

Degen

nice!

999 $ENJOY

Detective RW

lfg

mongmong

MINTED

Lego

degen

degen

degen

ahoy

Detective

111 $enjoy

1000 $enjoy

1000 $enjoy

degen

minted!

10 $degen

Degen

lfg!

111 $ENJOY

1 $Enjoy

100

cool

10 $Degen

20

perl!!

100 $DEGEN

777 $enjoy

dmitn!

dd

LFG

그만 내

Degen

Nice

5

11

11

1000 $Enjoy

100 $ENJOY

760 $ENJOY

5000 $ENJOY

See all comments

IMAGE

1024x1024 2.5MB

Degen Detectives

This PFP is a collectible which is excluded from official Degen Detectives Collection. Don't mint this for any monetary benefits.

📶 60 comments • 84,156 est. $enjoy tips

1 $DEGEN

omg

10

777 $enjoy

1 $DEGEN

lfg!

333 $ENJOY
thanks

100 $ENJOY 1$DEGEN

11 $DEGEN

Degen

1000 $Enjoy

100 $Enjoy

lfg!

100 $ENJOY

1 $Enjoy

Degen

Degen!!

lfg!

777 $Enjoy

@zora good!!
to the moon!!

LFG

lol

1 $ENJOY

degen!

gogo

1 $DEGEN

Degen Detectives

NICE

111 $enjoy

100 $enjoy

3 $ENJOY

200

mongmong

$degen $enjoy

mitn!

3

5

777 $enjoy

lfg

5000 $enjoy

1000 $ENJOY

1000 $Enjoy

5555 $Enjoy

1000 $Enjoy

good

2222 $enjoy

100 $enjoy

10000 $Enjoy

100 $Enjoy

777 $Enjoy

111 $enjoy

IMAGINE

unique rare x degen

nice

100

Minted

1000 $Enjoy

2000 $enjoy

1111 $enjoy

49000 $ENJOY

See all comments

IMAGE

1024x1024 2.7MB

Degen Detectives

Apr 10

Sui Art Gallery Presenting To You Excluded Degen Detectives From Official Collection in Extended Version.

📶 42 comments • 149,085 est. $enjoy tips

wowow!
1500 $enjoy

21

Very beautiful))

yeah, detective

wowow spy degen version
3333 $enjoy

32

Lfg

handsome 100 $Enjoy

33

5000 $ENJOY

10

10000 $enjoy

unique rare degen detectives

Good

lfg

Let's go

77 $enjoy

50000 $ENJOY

777 $ENJOY

15

777 $Enjoy

33

3000 $enjoy

77 $IMAGINE and 77$ENJOY

beauty

100 $ENJOY

Foe the Detective Culture

Thanks Sui!

33

2345 $ENJOY

1000 $ENJOY

69420 $enjoy

Minted

!

333 $enjoy

100 $ENJOY

degen！

LFG!

1111 $Enjoy

111 $enjoy

andara1919

1 $Enjoy

See all comments

IMAGE

1024x1024 1.5MB

Lord Hanuman: The Great Monkey God

Hanuman is the son of Vayu, the god of the wind, and Anjana, a celestial nymph. As a baby, Hanuman tried to fly up and grab the sun, thinking it was a fruit. Indra, the king of the gods, struck Hanuman with a thunderbolt on the jaw, inspiring his name. "Hanu" means "jaw" and "man" means "prominent". Hanuman's name is a reminder of the precarious nature of unbridled power, and how it can often result in dangerous consequences when unguided.

📶 28 comments • 115,175 est. $enjoy tips

Apr 09

0x0955

The powerful Hanuman Knight

777 $Enjoy

Hanuman chalisa .

1000 $ENJOY

nice

10000 $enjoy

1000 $ENJOY Sui

hanuman

777 $engoy

1111 $enjoy

Monkey god 10 $Enjoy

God of monkeys

riya02

unique rare. monkey king. 44444 $degen

1

Oh God 30 $Enjoy

111 $enjoy
Imagine!

1

111 $Enjoy

Minted for the Monkey God Culture

god 2

nice art. thx

Minted

10 $ENJOY

15 $ENJOY

1000 $Enjoy

i admire him

100000 $ENJOY

See all comments

VIDEO

0:00 1024x1024 1.5MB View on Zora

Ketu: Snake Tail

In astrology, Ketu is a shadow planet that doesn't have a physical body, but is instead represented by its energy. It's said that Ketu has a serpent's tail in its body. Ketu is associated with spirituality and is worldly malefic but spiritually benefic. It's also the south node of the moon.

📶 16 comments • 999 est. $enjoy tips

$DEGEN

500 $degen

Tail

Minted

Full set Rauh and Keri, nice

DEGEN

111 $enjoy

69 $degen

777 $Enjoy
77 $Imagine

Degen

snaked

so good

Nice NFT

snake

111 $enjoy

50000

See all comments

IMAGE

1024x1024 1.9MB

Rahu : Snake Head

Rahu is said to be the snake head without the body, and the Sun and Moon exit from his throat when he tries to swallow them. This cycle creates the grahana, an eclipse of the Sun and the Moon, which represents Rahu's temporary revenge. Rahu is also said to cause eclipses on the luminaries themselves.

📶 35 comments • 115,015 est. $enjoy tips

神

Crank It Up

44444 $degen

5000 $ENJOY

Oh my based god! 50 $Enjoy

111 $Enjoy

Minted for the Culture

1000 $ENJOY

10000 $ENJOY

snake head!!!

nice snake)

$DEGEN2

1

okay i missed a lot of gods,but should take 2 more this one

web2username

i ll try to get all of gods,at lest what is able to get now)
3rd

1000 $ENJOY

10000 $ENJOY

It reminds me of MarkerMaker

It's like Sun and Moon but Uptrend and Downtrend

It can swallow Sun and Moon but can't eat it, only swallow because the natural movement of the market can't be stopped

BASED

LFG 500 $DEGEN

10 $enjoy

nice

111 $enjoy
Imagine!

1111 $enjoy

10000 $ENJOY

400 $enjoy

5000 $enjoy

Snake

Rahu

Minted

Nice to have one more

1111 $ENJOY

111 $enjoy

1000 $Enjoy

69000 $ENJOY

See all comments

IMAGE

1024x1024 1.8MB

Goddess Kali: Goddess Of Doomsday

Apr 07

In Hinduism, Kali is the goddess of death, time, and doomsday. She is also associated with sexuality, violence, and motherly love. Kali is the first of the ten Mahavidyas in the Hindu tantric tradition. She is also known as the Divine Mother, representing Kali in her role as Mother Nature. Kali is the ultimate expression of nature, both destructive and benevolent. She represents the force of time, carrying both destruction and creation of life and the universe.

📶 15 comments • 12,238 est. $enjoy tips

$ENJOY

RezaR2

Very good

20 $DEGEN

10000 $enjoy

Joined

11111 $DEGEN

300 $ENJOY

imagine

1

1111 $enjoy
1111 $imagine!
333 $higher

50 $enjoy

gj

100 $DEGEN

777 $Enjoy

See all comments

IMAGE

1024x1024 2.1MB

Yama: The God Of The Dead

Apr 07

Yama, the god of the dead. The Vedas describe him as the first man who died, blazing the path of mortality down which all humans have since followed. He is the guardian of the south (the region of death) and presides over the resting place of the dead, which is located under the earth.

📶 0 comments

See all comments

IMAGE

1024x1024 1.9MB

Shukracharya: Guru Of Demon

Apr 06

Shukracharya is a sage who taught the demons warfare, politics, and weapons. He is also known as Asuracharya or Shukra, and is associated with Friday and the gem diamond.

📶 0 comments

See all comments

IMAGE

1024x1024 1.9MB

Vayudev : God Of Wind And Space

Apr 05

Vayudev, also known as Vayu, is the Hindu god of wind, air, breath, and space. He is also the guardian of the northwest direction and is known as the spiritual father of Bhima and Hanuman. Vayu is also known as Anila, Pavana, Vyāna, Vāta, Tanuna, Mukhyaprana, and Bhima.

📶 0 comments

See all comments

IMAGE

1024x1024 1.7MB

Goddess Savitri : A Virtuous Wife

Apr 04

Savitri, goddess in Hindu mythology, the daughter of the solar deity Savitr and the wife of the creator god Brahma. The Mahabharata recounts how Savitri used the power of her dedication to her husband Satyavan to prevent Yama, the god of the death, from taking him when he was fated to die.

📶 0 comments

See all comments

IMAGE

1024x1024 1.9MB

Bala Krishna: A Mighty Warrior

Apr 03

Bala Krishna is the eighth son of Devaki and Vasudeva, and is said to have been born to fulfill the prophecy of slaying his tyrannical uncle, Kamsa, the king of Mathura. Legend also has it that Bala Krishna performed many miraculous acts. In the Bhagavata Purana, there is a story about Manigriva and Nalakuvara, which is associated with liberation. In the Bhagavad Gita, one interpretation is that Krishna taught a universal monotheistic religion, and that he is the Svayam Bhagavan.

📶 0 comments

See all comments

IMAGE

1024x1024 1.7MB

Sage Marichi: Mind Born Son Of Brahma

Apr 02

Sage Marichi is a prominent figure in Hindu mythology and one of the seven sages, or Saptarishi, who are praised in the Vedas. He is the mind-born son of Lord Brahma and is believed to embody the creative essence and serve as a link between the divine and mortal realms. Marichi is also the father of Kashyapa, and the grandfather of the gods and the demons.

📶 0 comments

See all comments

IMAGE

1024x1024 1.8MB

Lord Varuna: God Of Water

Apr 02

Varuna is the god of water, sky, and oceans. He is also the ruler of the sky realm and upholds cosmic and moral law. Varuna is the chief of the Adityas, a group of gods who share the duty of upholding cosmic and moral law with him. Varuna is also known as the god-sovereign and personification of divine authority.

📶 0 comments

See all comments

IMAGE

1024x1024 1.7MB

Sage Atri: Mind Born Son Of Brahma

Apr 01

Atri is a great sage. He is one of the Manasputra, the mind-born sons of Brahma. Atri is also a Saptarishi, the seven great sages. His wife is Anasuya. Atri is credited with composing many hymns on Vedic gods such as Indra and Agni. The fifth Mandala of the Rig Veda, Atri Mandala, is named after Sage Atri.

📶 0 comments

See all comments

IMAGE

1024x1024 1.6MB

Lord Krishna: God Of Love

Lord Krishna is a major deity in Hinduism, and is known as the god of love, compassion, tenderness, and protection. He is also known as the Dark One, and is often depicted with dark blue skin. Krishna is the eighth avatar of Vishnu, but is also worshiped as a god in his own right.

📶 0 comments

See all comments

IMAGE

1024x1024 2MB

Lord Shiva: The Destroyer

Lord Shiva is known as The Destroyer within the Trimurti, the Hinduism trinity which also includes Brahma and Vishnu. In the Shaivite tradition, Shiva is the Supreme Lord who creates, protects and transforms the universe.

📶 0 comments

See all comments

IMAGE

1024x1024 1.6MB

Vasuki : Tha Naga King

Vasuki is the king of the nagas, and is often depicted coiling around Shiva's neck. He is brother of Sheshnaga & the son of Kashyapa and Kadru, and the grandson of Brahma, the creator of the universe. Vasuki is also known as the king of snakes and is depicted with 1000 heads.
Vasuki's three coils represent the cycle of life in terms of time. His head, which is always positioned on Shiva's right shoulder, symbolizes Shiva's everlasting justice and laws to preserve the nature and order of the universe.

📶 0 comments

See all comments

IMAGE

1024x1024 1.7MB

Sheshnaga: The King Of All Serpents

Shesha Naga is believed to be the one who is accountable for the notion of the gravitational force and makes sure that all planets and stars orbit around each other.
Sheshnaga is said to hold all the planets of the universe on his hoods and to constantly sing the glories of Vishnu from all his mouths.
Lord Vishnu is usually portrayed as resting on Shesha Naga.

📶 0 comments

See all comments

IMAGE

1024x1024 1.6MB

Loki: The Shapeshifter

Loki was the preeminent shapeshifter amongst the gods and on various occasions, he took the form of a salmon, a flea, a fly, and a mare. He also took the form of human beings, such as an old woman named Thökk who fatefully refused to weep for the fallen Baldur.
Odin and Loki became blood brothers and undertook adventures with Thor.

📶 0 comments

See all comments

IMAGE

1080x1080 1.5MB

Loki: The Shapeshifter

He was the Preeminent Shapeshifter amongst the Gods and on various occasions, he took the form of A Salmon, A Flea, A Fly, and A Mare. He also took the form of human beings, such as an old woman named Thökk who fatefully refused to weep for the fallen Baldur.Odin and Loki became blood brothers and undertook adventures with Thor.

📶 0 comments

ⵔ

connect wallet

✕

Mint

See all comments

IMAGE

1080x1080 1.5MB

Loki: The Shapeshifter

He was the Preeminent Shapeshifter amongst the Gods and on various occasions, he took the form of A Salmon, A Flea, A Fly, and A Mare. He also took the form of human beings, such as an old woman named Thökk who fatefully refused to weep for the fallen Baldur.Odin and Loki became blood brothers and undertook adventures with Thor.

📶 0 comments

See all comments

IMAGE

1024x1024 1.8MB

Suryaputra Karna: The Invincible Warrior

Karna is the Son of the Sun God Surya. He is considered an Invincible Warrior and Ideal Donor. Karna is also known as "Daanveer Karna" because he donated his Armor(which would make him Invincible) and earrings and also gave away his gold tooth at the last moment. Karna never refused to give anything in charity to anyone who asked.

📶 0 comments

See all comments

IMAGE

1024x1024 1.7MB

Agni Dev: God Of Fire

Agni Dev is the God Of Fire, and is also the guardian of the southeast direction. He is a major god in the Vedic pantheon, and is prominent in the hymns of the Vedas and Brahmanas.

📶 0 comments

See all comments

IMAGE

1024x1024 1.7MB

Surya: Lord Of The Dawn

Lord Surya, also known as Aditya, is the Hindu Sun God and is considered the creator of the Solar System and the source of all life. He is the chief deity among the nine classical planets of Hindu antiquity, known as the Navagraha.

📶 0 comments

See all comments

IMAGE

1024x1024 1.7MB

Moon God: Governs Your Mind

Chandra is the embodied maternal life-giving and creative energy. It is believed that the Chandra affects the soul and subconscious of a person, sensory perception, and the emotional sphere. Moon is one of the 9 planets in Vedic Astrology, collectively known as Navagraha.

📶 0 comments

See all comments

IMAGE

1024x1024 1.7MB

Lord Vishnu: The Preserver Of Universe

Mar 29

Lord Vishnu is considered the Preserver of the Universe and the Supreme God. He appears on earth in various forms to restore cosmic order and annihilate miscreants and sinners.

📶 0 comments

See all comments

IMAGE

1024x1024 1.3MB

Abhimanyu: Warrior By Birth

Mar 29

Abhimanyu is portrayed as a young, strong and talented warrior. He was also one of the few individuals, along with his father, who knew the technique to enter the Chakravyuha, a powerful military formation. Abhimanyu was 16 years old, when he was killed on the 13th day of the Kurukshetra war inside the Chakravyuha.

📶 0 comments

See all comments

IMAGE

1024x1024 1.8MB

Yudhishthira: Yama Dharma Raja

Mar 29

Yudhishthira, also known as Dharmaraja, is the king of Indraprastha and later the Kuru Kingdom in ancient Indian history. He is the eldest of the five Pandava brothers and a central figure in the Hindu epic Mahabharata.

📶 0 comments

See all comments

IMAGE

1024x1024 1.9MB

Poseidon: God Of Sea

Poseidon a.k.a. Samudradeva is one of the most powerful God, ruling over the oceans and all bodies of water. He is especially important to sailors and fisherman

📶 0 comments

See all comments

IMAGE

1024x1024 1.3MB

Sahdeva: The Fortune Teller

Sahdeva is a great astrologer and could see the future but the rule is that he can't foretell, unless asked.

📶 0 comments

See all comments

IMAGE

1024x1024 1.6MB

Urmila: The Forgotten Heroine Of Epic Ramayana

Urmila is often referred to as "the forgotten heroine" because the Epic Ramayana makes very few references to her.
When Lakshmana went into exile, he asked Urmila to stay back and take care of her in-laws, so she slept through the entire 14 years of his exile with Rama and Sita. This selfless sacrifice is often praised in the Ramayana.

📶 0 comments

See all comments

IMAGE

1024x1024 1.8MB

Trijata: Guards Mata Sita