Discussions

txhash: 06A1985A7466547795C0049ABA17DE9CC2CC298E742AC2E542C7F0F0CDEE692D this is my first attempt on v2, I need help for this case I get a generic temMALFORMED response using accept.wasm hex string {"Hooks":[{"Hook":{"CreateCode":"0061736D01000000011F0560057F7F7F7F7F017E60037F7F7E017E60027F7F017F60000060017E017E02230303656E76057472616365000003656E7606616363657074000103656E76025F6700020304030304040405017001010105030100020621057F0141B088040B7F0041A6080B7F004180080B7F0041B088040B7F004180080B076608066D656D6F72790200115F5F7761736D5F63616C6C5F63746F727300030A5F5F646174615F656E6403010D5F5F676C6F62616C5F6261736503020B5F5F686561705F6261736503030C5F5F64736F5F68616E646C650304046362616B000404686F6F6B00050ABB010302000B2702037F017E238080808000210141102102200120026B2103420021042003200037030820040F0B8D0103037F017E087F238080808000210141102102200120026B2103200324808080800042002104410121054100210641808880800021074114210841948880800021094112210A20032000370308200720082009200A20061080808080001A2006200620041081808080001A200520051082808080001A4110210B2003200B6A210C200C24808080800020040F0B0B2D01004180080B26224163636570742E633A2043616C6C65642E22004163636570742E633A2043616C6C65642E00003A046E616D6501330600057472616365010661636365707402025F6703115F5F7761736D5F63616C6C5F63746F727304046362616B0504686F6F6B00750970726F647563657273010C70726F6365737365642D62790105636C616E6755392E302E30202868747470733A2F2F6769746875622E636F6D2F6C6C766D2F6C6C766D2D70726F6A656374203033393964356139363832623363656637316336353333373365333838393063363363346333363529","HookApiVersion":0,"HookNamespace":"C125D0397B605657BC89340953F5F2897A7E00A9B7D3474FA53720C8CCBBB3E3","HookOn":"0000000000000000"}}],"TransactionType":"SetHook","Account":"rLnT5MeahSnbR8j7dRXa39iD3Wpd9b8E2F","Sequence":1797094,"LastLedgerSequence":2091835,"Fee":"10000000","Flags":0}

Hallo, I migrated my code from v1 to v2 and am having some issues. 1) I have to pay at least 2 XRP for all transactions (not just the setHook tx) to be validated. And even then it takes between 5 and 10 ledgers. Is that normal? 2) I can't "trace" variables. Example: Works: TRACEVAR(5); - logs: "5 5" Doesn't work: uint8_t x = 5; TRACEVAR(x); - logs: "x " I've tried with and without the TRACEVAR macro, with self-set variables and variables retrieved from state, but it doesn't work. But the variables are set because the code works fine. Did something change when logging into v2 that I missed? Appreciate any help! Greets Chris

Hi guys, I can't reach V1. Temporary or permanent?

Hi, I've been trying to install my hook on V2 now for a while - to no avail. I can't even install the hook from the documentation... Debugging says: Trying to wasm instantiate proposed hook size = 711 GuardCheck Total worse-case execution count: 1 GuardCheck Total worse-case execution count: 16 GuardCheck Total worse-case execution count: 285 Trying to wasm instantiate proposed hook size = 711 In a loop until the tx fails because of the last ledger sequence. Any suggestions what could cause this behaviour?

Hey, I was just wondering if there is a way to get the current timestamp on an incoming transaction?

The way hooks operate on-chain, would it be possible to deploy a Hook that facilitates flash loans to users? Since the XRPL requires a Hook to finish executing on the same ledger it was triggered, I think it's definitely possible to deploy a flash loan provider/platform. If anyone is interested to learn more about flash loans, do read: - https://www.blocksecteam.com/papers/sbc21_flashloan.pdf

Me and Denis Angell are particularly confused about the Hooks Chaining feature, maybe Richard could elaborate this feature to us? I'm wondering what the documentation means by 'remote account', is this related to the positioning of attached Hooks on the Sending and Receiving account? I'm not confident about the Sending/Receiving account being related to this feature, since on the #0 Chain position, it describes to us that the Hook on the *host* account is executed and no particular Receiving account is mentioned as well. [Most Likely Answer Below] Or is the Hook Chaining feature allowing us to position Hooks on our account by priority? Let's say I have 2 Hooks on my account, a Carbon Hook (sends a sum to a specified account) & a Firewall Hook (checks a list...), I want the Firewall Hook to be executed first before the Carbon Hook. So I specify the Firewall Hook @ Chain Position #-3 and the Carbon Hook @ Chain Position #-2 in this particular scenario. If my guess is right, then Hooks Chaining is really valuable to the amendment :) . Mindless recommendation: Rather then only allowing users to input a Hook's position by priority(#), what about XRP / IOUs amount? E.g: If payment >= 1,000,000 XRP: #1: Carbon -> #2: Firewall If payment >= 1,000 XRP: #1: Firewall -> #2: Carbon ^ Ignore the logic for now, I'm guessing it'll fail if the account is listed on a blacklist as it'll just rollback. Related doc: https://xrpl-hooks.readme.io/docs/execution-order#hook-chaining-future-feature

Hey, I was just wondering if the Hooks amendments is being delayed or everything is going as planned? When do you guys think the Hooks Amendment is being published on the mainnet, any guesstimate? Thank you.

I noticed there is no RPC endpoint on the hooknet. Is this your subtle way of telling me to migrate to web sockets in all my api calls to the XRPL? :) I realize I could open up one on my own, I just had some tests running that use RPC so I was curious.

I'm hoping to start a discussion orbiting around the error messages that the XRPL engine is returning when someone new (like me) is fumbling through all of this. I understand that _g is required from the documentation's perspective. However the error message we get back from the engine isn't helpful for seeing this is the problem when you don't include it. For instance if we don't include _g as an import you get a "Malformed transaction" error from the XRPL engine. Not super helpful for someone "down in the weeds" trying to learn. Interestingly if you include _g but don't use it in your hook you get a "temBAD_SIGNATURE" error from the engine. Again, not super helpful because it leads you down the path of "debugging" how you signed the transaction. I wonder if it could be a more clear about the reason for the "Bad Signature"? Any thoughts?