feat: add r/grc20reg

[moul]

Depends on #2743
Continues #1072
Related #1275, #1262
Depends on #1257
Depends on #2551
Alternative to #3135

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[moul]

Blocked by #2743

[r3v4s]

First of all, I know that this pr is sill working in progress, but couldn't wait for charming of supporting multiple grc20 tokens by default in gno-eco system(in this case grc20reg) and did some test.

Currently, grc20reg takes object from other realm to register it, and it seems like affects stack-frame. (tested with _test.gno)

On the other hand, testing with txtar slightly returns different result, cannot modify external-realm or non-realm object.
Is this due to #2743 you mentioned blocked by ??

[moul]

Yes, this grc20reg is no longer a work in progress, but it depends on the changes in the PR, specifically those in #2743.

For a preview of fully working examples, you can check my meta PR #2551, which includes some VM fixes, this completed realm, and other realms that use it, such as the atomicswap realm, for instance.

[r3v4s]

While testing with current grc20reg working version(#3135), I come up with few questions.

1. How are we(as gnoland) going to handle tokens that aren't registered to grc20reg?

• if registering token (to grc20reg) become as mandatory(for grc20 spec) you can ignore this question.

2. First of all, I thought re-entrancy might be possible because grc20reg allows us to call certain contract's function without import it, so tested with txtar.

• found out that calling transfer using grc20reg, is transfer from teller so re-ent isn't possible.

However, if token contract has certain logic located at before or after calling transfer(e.g), (since calling transfer by grc20reg calls teller.transfer) that logic won't be executed.

What do you think of this case??

[Gno2D2]

I'm a bot that assists the Gno Core team in maintaining this repository. My role is to ensure that contributors understand and follow our guidelines, helping to streamline the development process.

The following requirements must be fulfilled before a pull request can be merged.
Some requirement checks are automated and can be verified by the CI, while others need manual verification by a staff member.

These requirements are defined in this configuration file.

Automated Checks

🟢 Maintainers must be able to edit this pull request
🔴 The pull request head branch must be up-to-date with its base

Manual Checks

No manual checks match this pull request.

Debug

Automated Checks

Maintainers must be able to edit this pull request

If

🟢 Condition met
└── 🟢 On every pull request

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

The pull request head branch must be up-to-date with its base

If

🟢 Condition met
└── 🟢 On every pull request

Then

🔴 Requirement not satisfied
└── 🔴 Head branch (moul:dev/moul/grc20reg) is up to date with base (master): behind by 60 / ahead by 72

[moul]

You should either use the Approve pattern before Transfer or expect the user to use RealmTeller.