Bundle standards for contract systems as TOML

[ProgramCrafter]

Summary

I suggest to format message chain schemes for existing TEPs (jettons, NFTs) and non-TEP-contract systems in TOML format.

[jetton.info]
actor.admin.restrictions  = { nonnull = false }
actor.user.restrictions   = { nonnull = true, workchain = 0 }
actor.admin.source  = 'stdw'
actor.user.source   = 'stdw'

actor.jetton.restrictions = { nonnull = true }
actor.jetton.dependencies = ['actor.admin']
actor.jetton.source = 'tep74'
actor.wallet.restrictions = { nonnull = true, workchain = 0 }
actor.wallet.dependencies = ['actor.user', 'actor.jetton']
actor.wallet.source = 'tep74'

[jetton.info.related.tep74]
text = 'TEP-74 (jettons)'
color = '#98EA00'

[jetton.info.related.stdw]
text = 'standard wallets in TON ecosystem'
color = '#0098EA'

################################################################################

[jetton.ops.burn]
ton-flow = { start-fund-messages = 2, excess-return = true }
participants = { user = 'actor.user', wallet = 'actor.wallet', jetton = 'actor.jetton' }

[[jetton.ops.burn.messages]]
payload = """
burn#595f07bc query_id:uint64 amount:(VarUInteger 16)
        response_destination:MsgAddress custom_payload:(Maybe ^Cell)
        = InternalMsgBody;"""
custom-definitions.query_id = { suggest = '$now' }
custom-definitions.response_destination = { suggest = '$src' }
custom-definitions.custom_payload = { force = '$null' }
source = 'user'
destination = 'wallet'

[[jetton.ops.burn.messages]]
payload = """
burn_notification#7bdd97de query_id:uint64 amount:VarUInteger 16 sender:MsgAddress
        response_destination:MsgAddress = InternalMsgBody;"""
source = 'wallet'
destination = 'jetton'

Context

The bundle will be then used for drawing interactive graphs (for documentation) and codegen for any given programming language. In particular, this footstep was inspired by #357.

This footstep refers to:

1. TEP-74 - jettons (already done, see link in references)
2. TEP-62 - NFT
3. highload wallets, v3 and v4
4. The Elector, validators, nominators and, maybe, The Config

References

• example TOML parser (warning: dirty code): https://gist.github.com/ProgramCrafter/1d694418e949e975c5eda688abb6eef5

Estimate suggested reward

• $1200 worth of TON ($300 per contract system)
• TON Footsteps NFT

[mr-tron]

A very unclear scheme with a lot of specifics unique to a particular contract. Different namespaces are mixed together haphazardly.

[ProgramCrafter]

@mr-tron To be clear, I don't claim for this scheme to be final (nor exhaustively describing what happens), it can be improved. Though, I guess that all TON official contracts can be described with the scheme like one I provided.

Nevertheless, should it be done, it needs to contain:

1. message chains, of course. <scope>.ops.<operation name>.messages + summary of accounts used there in .participants + information about how much TON to send;
2. scopes each actor comes from, so they can be coloured in auto-graphs;
3. data about how to visualize each message chain.

[andreypfau]

I suggest to format message chain schemes for existing TEPs

For this reason TL-B exists. Why do we need another way to describe schemes? To make even more confusion?

[ProgramCrafter]

Why do we need another way to describe schemes?

Because TL-B does not set message source, destination, nor the order of messages in the chain. Actually, this format is meant to be internal, to auto-generate documentation, so as not to make much confusion.

Improvements were suggested, in particular splitting possible operations on contract systems, their chains and visualizations.

[delovoyhomie]

This issue has been automatically closed due to 14 days of inactivity and lack of the additional information requested. Please feel free to reopen it if you wish to provide further details or require assistance.